The real advantage here is the release of Armin's u'' syntax addition proposal:<p><a href="http://www.python.org/dev/peps/pep-0414/" rel="nofollow">http://www.python.org/dev/peps/pep-0414/</a><p>In a nutshell, the 2.x version of declaring a unicode string is now valid (although redundant). From the PEP:<p><i>In many cases, Python 2 offered two ways of doing things for historical reasons. For example, inequality could be tested with both != and <> and integer literals could be specified with an optional L suffix. Such redundancies have been eliminated in Python 3, which reduces the overall size of the language and improves consistency across developers.</i><p><i>In the original Python 3 design (up to and including Python 3.2), the explicit prefix syntax for unicode literals was deemed to fall into this category, as it is completely unnecessary in Python 3. However, the difference between those other cases and unicode literals is that the unicode literal prefix is not redundant in Python 2 code: it is a programmatically significant distinction that needs to be preserved in some fashion to avoid losing information.</i><p>This version of python should see more uptake by 2.x developers as it is now easier to port.
There are two significant factions in the Python community: the scientific group and the web-dev group. The scientific group is pretty much on board with Python 3. Perhaps due to unicode handling intricacies, that the web-dev group ain't exactly on board with Python 3 yet. But this needs to change and it takes leadership. Fortunately, bit and pieces such as webob are Python 3 compatible. And personally, I feel the Python web frameworks need a fresh redesign.
Exciting. Python 3.3 is the first release of the Python 3 series which makes me go from "I'll have to come around to use Python 3" to "dammit, why isn't my codebase under Python 3 yet?". There's a bunch of neat stuff, minor and not so minor.
I've done quite a bit of python development. One of the things that really bugs me about python is how they keep breaking older stuff. Other languages have been much more careful about maintaining backwards compatibility and I think that is a big factor in the retention of users.<p>Having to re-do any part of your code from one release of a language to another became a real deal breaker for me.<p>For an interpreted language that problem is even worse because you don't know you have a problem until that bit of code gets hit.
> The Python interpreter becomes aware of a pvenv.cfg file whose existence signals the base of a virtual environment’s directory tree<p>As someone who hated the .ini configuration for logging in python 2.5, this smells a bit.
"•A C implementation of the "decimal" module, with up to 80x speedup for decimal-heavy applications"<p>That in itself is should make a few python gamers happy. Also some serious motivations for older version users, not all but more and more. Also many other interesting develepments others have highlighted already.
I've always been uneasy about the increasing use of yield / generators in python these days, for instance, ndb in google app engine, twisted, etc. 'yield from' should make managing more complex uses of generators much easier - the question for me is, will this make me like widespread use of generators more, or will it make the use even more widespread, and still be kind of a pain to reason about, debug, etc.
Which Python version would you recommend to someone just starting to learn the language? I know "Learn Python the Hard Way" focuses on Python 2.7, and "Learning Python (4th Edition)" focuses primarily on Python 3.
Attending PyCon Ukraine 2011 it was very interesting to hear about Distutils2. But I see that in the end they are still not in Python3.<p>But even without it I am going to try Python3 in my projects (hello Django 1.5, Tornado, Wheezy.web, jinja2 and a lot of others).