
What’s New In Python 3.4 - ot
http://docs.python.org/dev/whatsnew/3.4.html
======
pixelmonkey
I didn't know what "Single Dispatch Functions" was all about. Sounded very
abstract. But it's actually pretty cool:

[http://www.python.org/dev/peps/pep-0443/](http://www.python.org/dev/peps/pep-0443/)

What's going on here is that Python has added support for another kind of
polymorphism known as "single dispatch".

This allows you to write a function with several implementations, each
associated with one or more types of input arguments. The "dispatcher" (called
'singledispatch' and implemented as a Python function decorator) figures out
which implementation to choose based on the type of the argument. It also
maintains a registry of types -> function implementations.

This is not technically "multimethods" \-- which can also be implemented as a
decorator, as GvR did in 2005[1] -- but it's related[2].

Also, the other interesting thing about this change is that the library is
already on Bitbucket[3] and PyPI[4] and has been tested to work as a backport
with Python 2.6+. So you can start using this _today_ , even if you're not on
3.x!

[1]
[http://www.artima.com/weblogs/viewpost.jsp?thread=101605](http://www.artima.com/weblogs/viewpost.jsp?thread=101605)

[2]
[http://en.wikipedia.org/wiki/Dynamic_dispatch](http://en.wikipedia.org/wiki/Dynamic_dispatch)

[3]
[https://bitbucket.org/ambv/singledispatch](https://bitbucket.org/ambv/singledispatch)

[4]
[https://pypi.python.org/pypi/singledispatch](https://pypi.python.org/pypi/singledispatch)

~~~
Pxtl
Wait, so it's language-supported external polymorphism? That's...odd, since
external polymorphism is considered an anti-pattern by OOP pl purists.

~~~
omaranto
Why is that odd? I don't think the Python community is mostly OOP purists.

------
rspeer
The thing I'm looking forward to in Python 3.4 is that you _should_ be able to
follow the wise advice about how to handle text in the modern era:

"Text is always Unicode. Read it in as UTF-8. Write it out as UTF-8.
Everything in between just works."

This was not true up through 3.2, because Unicode in Python <= 3.2 was an
abstraction that leaked some very unfortunate implementation details. There
was the chance that you were on a "narrow build" of Python, where Unicode
characters in memory were fixed to be two bytes long, so you couldn't perform
most operations on characters outside the Basic Multilingual Plane. You could
kind of fake it sometimes, but it meant you had to be thinking about "okay,
how is this text _really_ represented in memory" all the time, and explicitly
coding around the fact that two different installations of Python with the
same version number have different behavior.

Python 3.3 switched to a flexible string representation that eliminated the
need for narrow and wide builds. However, operations in this representation
weren't tested well enough for non-BMP characters, so running something like
text.lower() on arbitrary text could now give you a SystemError
([http://bugs.python.org/issue18183](http://bugs.python.org/issue18183)).

With that bug fixed in Python 3.4, that removes the last thing I know of
standing in the way of Unicode just working.

~~~
mineo
The advice you mention reminds me of the "Unicode sandwich", a term used by
Ned Batchelder in his awesome "Pragmatic Unicode" talk[0][1].

[0]
[http://nedbatchelder.com/text/unipain.html](http://nedbatchelder.com/text/unipain.html)
[1]
[http://nedbatchelder.com/text/unipain/unipain.html#35](http://nedbatchelder.com/text/unipain/unipain.html#35)

------
graue
I love how there's a thorough "what's new" document for a still-in-progress
release, and terms like "provisional API" are linked to a glossary that tells
you _exactly_ what they mean. While Python is not the most interesting
language to me anymore, it still sets the standard in clear, comprehensive,
newbie-friendly documentation.

~~~
tekacs
I think newbies are far from the people most likely to be looking at version-
to-version changelogs in any language.

This is great for those maintaining substantial codebases in the language,
though.

The thorough specification process gives lots of warning for the introduction
of changes (so you can almost update on release day if you were _really_ so
inclined and prepared).

Edit: Though on a re-read, clear, comprehensive newbie friendly documentation
is something that (somewhat unrelatedly) Python does have. My bad.

~~~
benjamincburns
I'm by no means a programming newbie, so maybe this skews what I'm about to
say, but I find that reviewing release notes and changelogs is often quite
useful while I'm still in the belly of a learning curve. If the project in
question has a cohesive vision (big "if"), this can help frame the trajectory
of that vision and get you to march in step with the project's state of the
art more quickly.

------
ot
I'm posting this mainly because it will be the first release that implements
PEP 3156 [1], that is, a standardized asynchronous I/O API.

[1]
[http://www.python.org/dev/peps/pep-3156/](http://www.python.org/dev/peps/pep-3156/)

~~~
lockes5hadow
Been waiting for this one for so long.

------
arocks
> "Tab-completion is now enabled by default in the interactive interpreter."

Thanks! Now I don't have to do this on every box anymore for using Python.

~~~
dmishe
Oh wait, you need to explicitly turn it on? How?

~~~
Jach
In your $PYTHONSTARTUP file:

    
    
        import readline
        import rlcompleter
        readline.parse_and_bind('tab: complete')

~~~
jsmeaton
Doesn't work on OSX like this. See below for portable version [1].

    
    
        import readline
        import rlcompleter
        if 'libedit' in readline.__doc__:
            readline.parse_and_bind("bind ^I rl_complete")
        else:
            readline.parse_and_bind("tab: complete")
    

[1]
[http://stackoverflow.com/a/7116997/10583](http://stackoverflow.com/a/7116997/10583)

------
LeafStorm
I like the implementation of the "Enum" class, especially the way they allow
for enums with variant behavior and "abstract Enums" (something I could have
used in Java recently).

But, ever since I found out about algebraic data types from other languages, I
keep wanting those. There's not quite a good way to do those in Python. (I've
used both "tuple subclass" and "__slots__," but both of those have their own
little quirks.)

~~~
shoo
if python were to have algebraic data types, it might also need pattern
matching.

~~~
gonnakillme
I don't think pattern matching is necessary for ADTs. It's useful, but you
could have e.g.

> if MyType.ConstructorA(a):

> ...

> elif MyType.ConstructorB(a):

> ...

or even something like

> with MyType.ConstructorA(a) as b, c:

> ...

> else with MyType.ConstructB(a) as d:

> ...

a "with/else with" construct would be a fairly straightforward addition to
Python's "context manager" interface.

------
eliben
Python 3.4 is one of the most feature-packed releases I recall. Besides the
obvious new perks like enums and asyncio, note some hidden gems like PEP 442:

" This PEP removes the current limitations and quirks of object finalization.
With it, objects with __del__() methods, as well as generators with finally
clauses, can be finalized when they are part of a reference cycle. "

This has been a notorious limitation in Python forever, and in 3.4 it's
finally solved.

~~~
gbog
I am not into the Python internals but I would suspect the widely critiqued
Python 3 step was just that: a shift that did not bring that much by itself
but rearranged the inners enough to allow unlocking a lot of new doors in the
future.

------
joliv
Finally, a statistics module! Actually though, simple methods for measures of
center and spread have been on my Python wishlist since, like, forever. The
mean() function is going to be especially useful. So excited!

------
panzi
Yay, code by me is now in an official Python release! (data:-URL support)

~~~
takluyver
Congratualations! It's also the first release with code I wrote (the
dis.Bytecode class).

------
nemothekid
Python 3.4 is out and unfortunately I still can't write Python3.

Is there anyone else who is still procrastinating moving their workflow to
Python3?

~~~
bobmoretti
I'm still on Python 2.7. I've built up a lot of infrastructure at work
surrounding the "scipy stack".

Are there any major libraries that have not yet been ported to Python 3? I'd
be interested to hear about others' experiences making the plunge.

~~~
takluyver
All of the core Scipy Stack is ported, though if you use more specialist
libraries, they may be missing. The main pain point in switching is with
unicode, which is mostly not an issue for scientific/numberical code. Watch
out, though, for integer division: now 1/2==0.5 (not 0).

~~~
analog31
> Watch out, though, for integer division: now 1/2==0.5 (not 0).

There go half of my bugs. ;-)

------
robomartin
Can someone help me understand how to think about the transition from 2.7.x to
3.x?

I have recently switched my work to Python and just started development on
what will become a series of web projects all done in Python + Django. Yes,
when it comes to Python I am a noob.

Looking at it with fresh eyes it seems that the most useful ecosystem is
solidly rooted in the 2.7.x branch. Books and online courses promote the idea
of using 2.7.x. My kid enrolled in the MIT intro to CS edX course and they use
2.7.5. Codecademy, same thing.

From the perspective of developing a number of non-trivial web-based products,
how should I view the 2.7.x and 3.x ecosystems? Do you see a timeline to a
transition? How should one prepare for it (or not)? What should one avoid?

At the moment it seems safe to pretty much ignore 3.x. I kind of hate that
because I have this intense desire to always work with the the latest stable
release of any software I use. Here things are different due to the
surrounding ecosystem of libraries and tools. I'd certainly appreciate any and
all help in understanding this a bit better.

~~~
SiVal
If you don't have any legacy baggage, you should celebrate your freedom to do
what hockey great Wayne Gretszky said was his secret to success: Don't skate
to where the puck is, skate to where it will be. The value of Python 2
knowledge is like the value of knowledge of how to write HTML/CSS for old
versions of IE: a declining asset. If you don't have to deliver production
software for today's user base, rejoice, and focus on learning how to target
tomorrow's user base. Python 3 + Django 15 already let you do that. Those
external libraries that don't work with Python 3 will either be upgraded or
replaced. There is probably a lot you can learn about Python 3 and the latest
Django while that takes place.

And, regarding kids, I'm teaching mine Python 3 only (no time wasted on Py 2)
and the latest HTML5/CSS3 (no time wasted learning workarounds for obsolete
browsers). I think they're better off focusing entirely on preparing for the
future, not spending part of their time preparing for the past.

~~~
robomartin
Thanks for your perspective on this. I had my kid go through the codecademy
python course, which is 2.7.5. Now he is going through the MIT CS class on
edX, which also seems to be 2.7.5.

At this point I'll help him through this phase and perhaps then make 3.x part
of the continuing learning experience. In other words, if you are going to be
in CS you will always have to deal with shifts in technology, this being a
perfect teaching moment for him to learn that.

------
Siecje
Unsupported Operating Systems

OS/2

------
tveita
It is strange that they claim to have implemented SHA-3 in hashlib. The
details of the padding and capacity are still under discussion, so no final
standard has been published yet.

------
ridhoq
I'm interested in seeing how robust this custom allocator feature will be. I
doubt it will be more efficient than C/C++ but it makes the language that much
more useful.

------
thearn4
The new statistics library looks interesting.

------
bluecalm
As to statistics module, wouldn't it be more useful to have median functions
with default percentile parameter (defaulting to 0.5) ? I mean, it's common
use case and seems like natural thing to have.

------
bluecalm
Enums and statistics module. Yay !

------
chrismorgan
"The :mod:: _pprint_ module" \- an extra : there has broken the reference.

------
lightcatcher
Python keeps getting more awesome, but we're still stuck at Python 2 :(

~~~
lockes5hadow
What's got you stuck?

~~~
scottlinux
django here.

~~~
deadbeef404
Django supports python 3, though I guess some django apps might not yet.
[https://docs.djangoproject.com/en/1.5/topics/python3/](https://docs.djangoproject.com/en/1.5/topics/python3/)

------
danbmil99
TL; DR: "No new syntax features are planned for Python 3.4."

------
algebr
Gahh, I wish my work wasn't frozen in 2.6.

~~~
jessaustin
What prevents migration to 2.7? It's nothing technical, is it?

------
adamlj
Finally Enums!

