In a nutshell, the 2.x version of declaring a unicode string is now valid (although redundant). From the PEP:
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.
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.
This version of python should see more uptake by 2.x developers as it is now easier to port.
Although it was a pain, it was manageable beforehand and in fact, if you need to support 3.1 or 3.2, you will still have to manage it a different way.
Many of the features detailed in the release list are more helpful in general. 'yield from' is actually really good if you are using generator based coroutines, the wide/narrow build thing addresses a long-time pain point, it will be great if namespace packages are actually fixed by now, and adoption of virtualenv into the core is a big deal!
This would have made it so much easier to create a version of Crunchy that could run transparently using either Python 2.x and 3.x. However, as much as I applaude this change, there are others new features in 3.3 that are just as important imo.
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.
I work in both camps, and I always felt it was the web developers that were better about moving on to 3. Scientists in general are loathe to risk breaking well-tested code for the sake of new features. In my research group, in fact, we've just barely moved on to 2.7 from 2.4! I doubt there will be any motivation at all for moving to 3 any time soon.
> There are two significant factions in the Python community: the scientific group and the web-dev group.
You forget the animation group. And the hardware/embedded group (Raspberry-Pi, anyone?). And the C-wrapper-writing group. And the sysadmin group. And and and...
The Python ecosystem is very large and diverse. That's part of its strength, and part of its weakness as well (it's very difficult to "herd" all these people, as this 3k migration has shown), but don't make the error of reducing it to the most vocal sectors -- they're not necessarily the most significant ones.
Last-Modified: 2011-01-16 09:57:25 +0000 (Sun, 16 Jan 2011)
...
Status: Final
...
Created: 26-Sep-2010
Until this was made final(January 2011), web frameworks that use the wsgi spec had no python 3 path short of ditching the wsgi spec.
Now that it is final, there is a path to python 3 for web-dev. Cherrpy got there first I think. Pyramid/Webob got there, and others as well, and I'm sure Django will get there soon enough.
I'd say web-dev adoption of python 3 has been pretty swift.
Have you looked at Pyramid? It's pretty awesome, really the ideal framework philosophy in my opinion (i.e., actually a framework instead of attempting to be a crappy domain-specific language/replacement standard library). It's also Python 3.x compatible and has been for several months (they replaced the one library they had been holding out for).
I gave Django a couple of truly honest tries, but I just couldn't bring myself to tolerate it. Pyramid is by far the best.
I believe that the lack of WSGI held web-dev group back for a long time. PEP3333 (WSGI for Py3k) was finalized in early 2011, over two years after the release of 3.0.
As a PHP developer I've been waiting for the web-dev group to jump on board with Python 3 before I make the switch. I'm hoping it will be sooner rather than later.
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.
Having to re-do any part of your code from one release of a language to another became a real deal breaker for me.
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.
Be careful what you wish for. The extreme alternative is Java, whose slavish obsession with backwards compatibility has effectively crippled the language. There's enough cruft in the standard library to keep newbies guessing for years, plus fundamental language design failures like type erasure and "beans".
At some point you need to burn bridges in order to move forward. Doing this frequently destroys the community. Never doing it also destroys the community, it just takes longer.
Personally, I think Python is managing pretty well. Yes, it's occasionally painful, but it's less painful than stagnation.
One of the things that really bugs me about python is how they keep breaking older stuff.
That's a fair point, and it applies to a lot more than just programming languages. Operating systems and browsers also come to mind, for example.
On the other hand, if you insist on maintaining strict backward compatibility indefinitely, you have increasing drag on every useful new feature you want to introduce. You also can't remove edge cases that should ideally never have been there, even if they make it easy to introduce a bug.
In programming languages, this is the C++ effect. Building on the familiar foundation of C was a good decision by Stroustrup in the early days, and I'm sure it contributed greatly to C++'s success. On the other hand, today I believe that C++ is holding back large parts of the programming community, by being good enough in its niche that huge numbers of projects stick with it, yet lacking the expressive power, broad standard library functionality, and clean syntax/semantics that we take for granted in numerous modern programming languages.
In general, the goals of stability and progress are always going to be in conflict for any platform-like software. Such software essentially defines a standard for others to program against, and the entire point of standards is to create stability and common ground, but sometimes old standards don't adapt well to incorporate new ideas.
I suspect the best we can ever do is restrict major changes, which in practice means those where the old code cannot be automatically converted to get the same behaviour on the new system, to major releases. Minor changes that can be automatically converted are much less of a problem, as long as the "breaking" version of the platform comes with a simple conversion tool.
To be fair to the Python developers, this is essentially what they've done with the jump from Python 2 to Python 3. There is a tool to deal with converting the trivia, and most of the breaking changes were in the initial jump and acknowledged as such.
There probably is a case for making fewer, if any, breaking changes in minor releases. On the other hand, if you're looking at an estimated period of five years to migrate the bulk of the community from one major version to the next, there is probably a fair case for allowing a few smaller but incompatible changes in minor versions as well, as long as their effects are clear and only within a tightly controlled scope so they don't unduly disrupt everyone they aren't there to help.
If you're talking about breakage between version 2 and 3 that is sort of what the major version number bump implies. I don't do much python work these days, but if stuff is (deliberately) breaking between minor releases I would agree that's not very nice.
The problem is in the type system. Dynamic typing makes it difficult to ever change APIs, because a change could break anything that depends on them. pylint and other such tools help a little bit, but they can only do so much when the language doesn't support static typing.
Another Python feature that makes upgrades hard is monkeypatching, where one piece of code can inject arbitrary code into another piece of code. In many dynamic languages, this is often used to patch the behavior of core classes like String. I don't know how common this is in Python, but I've definitely seen it before. By erasing the distinction between interface and implementation, this makes it difficult to ever change them implementation of anything.
People say that writing more and more unit tests will solve these problems. But guess what? The more unit tests you have of an API, the more unit tests you have to change when that API changes. Unit tests are good and should be written in any language, but they are hardly a substitute for static typing.
The end result of all of this is that dynamically typed languages usually follow a trajectory where there's an initial burst of enthusiasm about some cool syntax, followed by a lot of code being written, and then a gradual descent into a compatibility tarpit, where nothing can be changed because of fear of breaking working code. Only additions can be made, and the language gradually grows uglier and uglier. Dynamically typed languages approximate Bourne shell more and more as time goes on-- a dozen slightly incompatible implementations, ancient quirks that bite hard on newcomers, and a resignation that this is the "best it gets."
Sometimes there's a burst of irrational hope towards the end of a language's lifetime. Perl 6 and Python 3 are good example of this. Developers go into their happy place and forget about the big bad compatibility bear that's been chasing them. But it's just a fantasy-- dynamic languages can't escape from the tarpit in the end, and nobody adopts the new thing.
"•A C implementation of the "decimal" module, with up to 80x speedup for decimal-heavy applications"
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.
The `whole greater than the tally` feature set and performance improvements of this release, really has inched Python 3 to the point where I will want to start using it. With no basis beyond my own and other's like sentiment this still seems like an important milestone. Feel like many will move from inertiaville, at least building a weekend house in momentum town.
Some comments were deferred for faster rendering.
po|13 years ago
http://www.python.org/dev/peps/pep-0414/
In a nutshell, the 2.x version of declaring a unicode string is now valid (although redundant). From the PEP:
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.
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.
This version of python should see more uptake by 2.x developers as it is now easier to port.
slurgfest|13 years ago
Many of the features detailed in the release list are more helpful in general. 'yield from' is actually really good if you are using generator based coroutines, the wide/narrow build thing addresses a long-time pain point, it will be great if namespace packages are actually fixed by now, and adoption of virtualenv into the core is a big deal!
aroberge|13 years ago
vph|13 years ago
wwwtyro|13 years ago
toyg|13 years ago
You forget the animation group. And the hardware/embedded group (Raspberry-Pi, anyone?). And the C-wrapper-writing group. And the sysadmin group. And and and...
The Python ecosystem is very large and diverse. That's part of its strength, and part of its weakness as well (it's very difficult to "herd" all these people, as this 3k migration has shown), but don't make the error of reducing it to the most vocal sectors -- they're not necessarily the most significant ones.
tbatterii|13 years ago
Last-Modified: 2011-01-16 09:57:25 +0000 (Sun, 16 Jan 2011) ... Status: Final ... Created: 26-Sep-2010
Until this was made final(January 2011), web frameworks that use the wsgi spec had no python 3 path short of ditching the wsgi spec.
Now that it is final, there is a path to python 3 for web-dev. Cherrpy got there first I think. Pyramid/Webob got there, and others as well, and I'm sure Django will get there soon enough.
I'd say web-dev adoption of python 3 has been pretty swift.
denzil_correa|13 years ago
Ah .. NO! I can assure you that we are still stuck with Python 2.x (2.7 to be more precise). I am not too sure the others would have moved either.
cookiecaper|13 years ago
I gave Django a couple of truly honest tries, but I just couldn't bring myself to tolerate it. Pyramid is by far the best.
srj55|13 years ago
zokier|13 years ago
symbiotic|13 years ago
unknown|13 years ago
[deleted]
masklinn|13 years ago
reinhardt|13 years ago
tisme|13 years ago
Having to re-do any part of your code from one release of a language to another became a real deal breaker for me.
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.
stickfigure|13 years ago
At some point you need to burn bridges in order to move forward. Doing this frequently destroys the community. Never doing it also destroys the community, it just takes longer.
Personally, I think Python is managing pretty well. Yes, it's occasionally painful, but it's less painful than stagnation.
Silhouette|13 years ago
That's a fair point, and it applies to a lot more than just programming languages. Operating systems and browsers also come to mind, for example.
On the other hand, if you insist on maintaining strict backward compatibility indefinitely, you have increasing drag on every useful new feature you want to introduce. You also can't remove edge cases that should ideally never have been there, even if they make it easy to introduce a bug.
In programming languages, this is the C++ effect. Building on the familiar foundation of C was a good decision by Stroustrup in the early days, and I'm sure it contributed greatly to C++'s success. On the other hand, today I believe that C++ is holding back large parts of the programming community, by being good enough in its niche that huge numbers of projects stick with it, yet lacking the expressive power, broad standard library functionality, and clean syntax/semantics that we take for granted in numerous modern programming languages.
In general, the goals of stability and progress are always going to be in conflict for any platform-like software. Such software essentially defines a standard for others to program against, and the entire point of standards is to create stability and common ground, but sometimes old standards don't adapt well to incorporate new ideas.
I suspect the best we can ever do is restrict major changes, which in practice means those where the old code cannot be automatically converted to get the same behaviour on the new system, to major releases. Minor changes that can be automatically converted are much less of a problem, as long as the "breaking" version of the platform comes with a simple conversion tool.
To be fair to the Python developers, this is essentially what they've done with the jump from Python 2 to Python 3. There is a tool to deal with converting the trivia, and most of the breaking changes were in the initial jump and acknowledged as such.
There probably is a case for making fewer, if any, breaking changes in minor releases. On the other hand, if you're looking at an estimated period of five years to migrate the bulk of the community from one major version to the next, there is probably a fair case for allowing a few smaller but incompatible changes in minor versions as well, as long as their effects are clear and only within a tightly controlled scope so they don't unduly disrupt everyone they aren't there to help.
ams6110|13 years ago
krosaen|13 years ago
d0mine|13 years ago
rbanffy|13 years ago
The easiest way around this problem is to have tests and run them before you upgrade your production boxes. It's not that hard to do.
rdtsc|13 years ago
What are specific APIs or things they keep continuously breaking? Did you have issues with transition from 1 to 2 and now with 2 to 3.
unknown|13 years ago
[deleted]
protomyth|13 years ago
cmccabe|13 years ago
Another Python feature that makes upgrades hard is monkeypatching, where one piece of code can inject arbitrary code into another piece of code. In many dynamic languages, this is often used to patch the behavior of core classes like String. I don't know how common this is in Python, but I've definitely seen it before. By erasing the distinction between interface and implementation, this makes it difficult to ever change them implementation of anything.
People say that writing more and more unit tests will solve these problems. But guess what? The more unit tests you have of an API, the more unit tests you have to change when that API changes. Unit tests are good and should be written in any language, but they are hardly a substitute for static typing.
The end result of all of this is that dynamically typed languages usually follow a trajectory where there's an initial burst of enthusiasm about some cool syntax, followed by a lot of code being written, and then a gradual descent into a compatibility tarpit, where nothing can be changed because of fear of breaking working code. Only additions can be made, and the language gradually grows uglier and uglier. Dynamically typed languages approximate Bourne shell more and more as time goes on-- a dozen slightly incompatible implementations, ancient quirks that bite hard on newcomers, and a resignation that this is the "best it gets."
Sometimes there's a burst of irrational hope towards the end of a language's lifetime. Perl 6 and Python 3 are good example of this. Developers go into their happy place and forget about the big bad compatibility bear that's been chasing them. But it's just a fantasy-- dynamic languages can't escape from the tarpit in the end, and nobody adopts the new thing.
pkmays|13 years ago
csense|13 years ago
facorreia|13 years ago
endlessvoid94|13 years ago
As someone who hated the .ini configuration for logging in python 2.5, this smells a bit.
TazeTSchnitzel|13 years ago
sigzero|13 years ago
http://docs.python.org/py3k/whatsnew/3.3.html
Zenst|13 years ago
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.
janzer|13 years ago
ralph|13 years ago
unknown|13 years ago
[deleted]
unknown|13 years ago
[deleted]
unknown|13 years ago
[deleted]
krosaen|13 years ago
coolnow|13 years ago
magnusgraviti|13 years ago
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).
Ixiaus|13 years ago
TazeTSchnitzel|13 years ago
sigzero|13 years ago
johnisme|13 years ago
sublimit|13 years ago
masklinn|13 years ago
I can't make head or tail of that claim, what's the "bloat since 3.0"?
Shish2k|13 years ago
[deleted]
castles|13 years ago
castles|13 years ago