Python 3.0: What's The Point?(mooseyard.com)
mooseyard.com
Python 3.0: What's The Point?
http://mooseyard.com/Jens/2008/12/python-30-whats-the-point/
32 comments
UNICODE support would be reason enough to answer "what's the point".
Also, some operations in Python 3, particularly those that are relevant to me as a web application developer, are as fast as 2.6 and in fact significantly faster than 2.5.x.
If for no other reason than the much better support for Unicode - an advantage that will pay off dividends across all products built on 3 in the future - that would be reason enough.
As it is when you look at third party packages that claim to support Unicode you'll frequently find all sorts of cruft that doesn't play well with other packages.
With respect to Unicode and Python, what was once less than intuitive, is now easy. It just works.
Also, some operations in Python 3, particularly those that are relevant to me as a web application developer, are as fast as 2.6 and in fact significantly faster than 2.5.x.
If for no other reason than the much better support for Unicode - an advantage that will pay off dividends across all products built on 3 in the future - that would be reason enough.
As it is when you look at third party packages that claim to support Unicode you'll frequently find all sorts of cruft that doesn't play well with other packages.
With respect to Unicode and Python, what was once less than intuitive, is now easy. It just works.
What, specifically, are the areas in Py3k that you use regularly as a web developer that are faster in Py3k than they were in Python 2.5?
Certain libraries (both standard and 3rd party) perform significantly better - in part because there appear to be some performance improvements in 2.6 which 3.0 also benefits from.
Standard ElementTree (pure python) is roughly 40% faster in Python 3 than in 2.5. cElementTree is likewise about 40% faster. A templating package I use runs 3 times slower on 2.5 than on 2.6 and 3.0 (similar performance on 2.6 and 3.0).
Bearing in mind that optimization work will follow on, I believe being "fast enough" is a good achievement for Python 3 and I'm personally pleased that performance will not be a roadblock for my own adoption. Where I can live on the bleeding edge I plan to.
Standard ElementTree (pure python) is roughly 40% faster in Python 3 than in 2.5. cElementTree is likewise about 40% faster. A templating package I use runs 3 times slower on 2.5 than on 2.6 and 3.0 (similar performance on 2.6 and 3.0).
Bearing in mind that optimization work will follow on, I believe being "fast enough" is a good achievement for Python 3 and I'm personally pleased that performance will not be a roadblock for my own adoption. Where I can live on the bleeding edge I plan to.
Sounds a bit like all the VB Classic guys moaning about VB.NET. I joined in a bit myself (mind .NET 1.0 was pretty bad) but now quite happily work in C#, VB.NET and VB6 - whatever makes the customer happy.
Many thousands of VB programmers (hundreds of thousands?) bridged the gap and a great many work in both versions just like me. It just is not a problem.
Many thousands of VB programmers (hundreds of thousands?) bridged the gap and a great many work in both versions just like me. It just is not a problem.
Nope, thousands at best.
Most abandoned Microsoft. Or better said, Microsoft abandoned them. Choosing to release an incompatible set of new languages with no upgrade path was hint enough that Microsoft had purely it's own interests at heart and not that of the lowly VB and ASP developers who made their OS and web server successful. Most took the hint and are now happily supporting Java, Ruby, PHP, Python and Perl web apps (with a side-business supporting VB6 legacy apps and ASP - apparently still alive and kicking after all these years) -in short, anything non-proprietary.
"Fool me once; shame on you. Fool me twice; shame on me." For Microsoft, no second chance.
Most abandoned Microsoft. Or better said, Microsoft abandoned them. Choosing to release an incompatible set of new languages with no upgrade path was hint enough that Microsoft had purely it's own interests at heart and not that of the lowly VB and ASP developers who made their OS and web server successful. Most took the hint and are now happily supporting Java, Ruby, PHP, Python and Perl web apps (with a side-business supporting VB6 legacy apps and ASP - apparently still alive and kicking after all these years) -in short, anything non-proprietary.
"Fool me once; shame on you. Fool me twice; shame on me." For Microsoft, no second chance.
I think MS misjudged its audience there (a rare stumble for them). Visual C++ people thought of their work as code and expected to have to change it for a new version. For them the transition to managed C++ or C# was natural. Visual Basic people thought of their work as documents and were as surprised as if MS had released version of Word that couldn't read documents from the previous version.
I have never heard or read a VB programmer describe his work as a _document_! No, the problem was not how "Visual Basic people thought of their work".
The problem was that VB.NET was a completely different language from VB6, with the full consequences therof: no upgrade path for existing code, retraining of all personnel, etc.
On IIS the upgrade to ASP.NET required purchase of a new IDE (Visual Studio) for all developers and retraining of all personnel, (ASP required no IDE). And ASP.NET abandoned support of VBScript which was by far the most popular ASP language.
The problem was that VB.NET was a completely different language from VB6, with the full consequences therof: no upgrade path for existing code, retraining of all personnel, etc.
On IIS the upgrade to ASP.NET required purchase of a new IDE (Visual Studio) for all developers and retraining of all personnel, (ASP required no IDE). And ASP.NET abandoned support of VBScript which was by far the most popular ASP language.
Not quite.
The "document" might perhaps be how some VB programmers conceived of their code - as a totality not just a collection of code lines delivering an algorithm - but perhaps you are right and this is not an idea that you can take very far.
I am not sure that I agree that VB.NET was "completely different" - different yes, but still clearly a dialect of Basic (of which there have been many - and some new ones popping up all the time). I suspect that you overstate the difficulty in migrating from one dialect to another - sure it is going to take time to reach similar levels of productivity but time and languages move on - it's something that programmers above all should be glad to embrace.
On your final point - ASP.NET does not in fact require the Visual Studio IDE. There are many advantages to be gained from the IDE but it is not a requirement and there are many texts around that demonstrate development outside of VS. OK VBScript was coming to the end of it's life but in any case it's client side (browser) utility was very limited and something more powerful was certainly needed server side. Oddly - the next generation of VB.NET will include a dynamic option - son of VBScript perhaps?
The "document" might perhaps be how some VB programmers conceived of their code - as a totality not just a collection of code lines delivering an algorithm - but perhaps you are right and this is not an idea that you can take very far.
I am not sure that I agree that VB.NET was "completely different" - different yes, but still clearly a dialect of Basic (of which there have been many - and some new ones popping up all the time). I suspect that you overstate the difficulty in migrating from one dialect to another - sure it is going to take time to reach similar levels of productivity but time and languages move on - it's something that programmers above all should be glad to embrace.
On your final point - ASP.NET does not in fact require the Visual Studio IDE. There are many advantages to be gained from the IDE but it is not a requirement and there are many texts around that demonstrate development outside of VS. OK VBScript was coming to the end of it's life but in any case it's client side (browser) utility was very limited and something more powerful was certainly needed server side. Oddly - the next generation of VB.NET will include a dynamic option - son of VBScript perhaps?
Just spotted this response - astute!
That might well explain the unwillingness of so many to move over even after .NET started to deliver the goods (from version 1.1)
That might well explain the unwillingness of so many to move over even after .NET started to deliver the goods (from version 1.1)
I think the stats show that VB.NET is the most popular .NET language - so I think we are talking many more than thousands.
I think, though, a number of programmers did leave Visual Basic for other things over those changes. Is that not correct?
I wanted to like Jens' article, as a fellow Rubyist who had left a few 10klocs of Python in his wake. But I thought this was really weak. Instead of coming across like genuine tough questions, I think Jens wears his bias on his shoulder, even commenting that he's been "tipped more towards Ruby" by this "fork in the community" (a particularly funny comment from a Rubyist).
His worst argument: a comment that claims he's worried that Py3k will get security fixes that Python 2.6 won't --- a borderline-irresponsible cheap shot.
It's too bad, because I actually agree with his assessment; I get a whiff of "second-system syndrome" from this whole Py3k project, and the idea of breaking random bits of code in an interpreted, dynamically typed language and then fixing them with a code translator seems like lunacy.
His worst argument: a comment that claims he's worried that Py3k will get security fixes that Python 2.6 won't --- a borderline-irresponsible cheap shot.
It's too bad, because I actually agree with his assessment; I get a whiff of "second-system syndrome" from this whole Py3k project, and the idea of breaking random bits of code in an interpreted, dynamically typed language and then fixing them with a code translator seems like lunacy.
"second-system syndrome" sounds like exactly the opposite of what I think about py3k. (Pythonista with more than 10kloc, rubyist at my day job, many less).
Mainly, I see this release as cleaning up the warts that python had accumulated. {imap, ifilter, izip, iterkeys, itervalues, iteritems, xrange} all becoming default and their non-stream counterparts ceasing to exist is a huge upgrade.
Unifying new-style and old-style classes is a huge cleanup and upgrade. (Which simplifies code for newbies quite a bit, too).
The move to default unicode strings is a huge upgrade.
The library cleanup is a huge upgrade.
The inclusion of multiprocessing (actually 2.6, but who uses that?) is a huge upgrade.
I don't see any of this as "breaking random bits of code", but rather as stepping back to regroup the language into a much more coherent whole.
But then, I'm in the tank for python, I freely admit.
Mainly, I see this release as cleaning up the warts that python had accumulated. {imap, ifilter, izip, iterkeys, itervalues, iteritems, xrange} all becoming default and their non-stream counterparts ceasing to exist is a huge upgrade.
Unifying new-style and old-style classes is a huge cleanup and upgrade. (Which simplifies code for newbies quite a bit, too).
The move to default unicode strings is a huge upgrade.
The library cleanup is a huge upgrade.
The inclusion of multiprocessing (actually 2.6, but who uses that?) is a huge upgrade.
I don't see any of this as "breaking random bits of code", but rather as stepping back to regroup the language into a much more coherent whole.
But then, I'm in the tank for python, I freely admit.
I knew when I wrote "second-system syndrome" that I was going to get hammered for it, because I agree that it's not a perfect match for what they've done.
Many millions of lines of Python code work in the field right now; a decent subset uses Unicode (for instance, most Win32 Python code has to). I buy that the new Unicode model is better, but I don't buy that it's so much better that a code port is worth it.
The library cleanup is a major win, but they could have done that in Python 2.7.
It's hard to say multiprocessing is a huge win in 3.0, since it's already in 2.x.
Many millions of lines of Python code work in the field right now; a decent subset uses Unicode (for instance, most Win32 Python code has to). I buy that the new Unicode model is better, but I don't buy that it's so much better that a code port is worth it.
The library cleanup is a major win, but they could have done that in Python 2.7.
It's hard to say multiprocessing is a huge win in 3.0, since it's already in 2.x.
> It's hard to say multiprocessing is a huge win in 3.0, since it's already in 2.x.
Yeah, I was just joking about that bit.
I don't see why it would be any different for the 2.7 library have been reorganized than it is for the 3.0 library reorganization; it would have broken just as much code. And while you're breaking code, you should break the code that needs to be broken, right?
And it's not just unicode, it's unicode/new style classes/iterators throughout (which I think is an underrated change). None of these could have happened without breakage, and I think it's better to clear the decks once every 15 years than it is to just grow by accretion forever.
Those lines of python in the field that work are not going to stop working; python 2.x is not going to go away or go unmaintained, as you point out yourself. Writing new code will shortly become more difficult in the 2.x series, as libraries start switching to 3, but the old code will be maintainable for a long while.
In order for the language to keep growing in a clean, pythonic fashion, it needed to be cleaned up a bit, and I think they did a great job of it.
Yeah, I was just joking about that bit.
I don't see why it would be any different for the 2.7 library have been reorganized than it is for the 3.0 library reorganization; it would have broken just as much code. And while you're breaking code, you should break the code that needs to be broken, right?
And it's not just unicode, it's unicode/new style classes/iterators throughout (which I think is an underrated change). None of these could have happened without breakage, and I think it's better to clear the decks once every 15 years than it is to just grow by accretion forever.
Those lines of python in the field that work are not going to stop working; python 2.x is not going to go away or go unmaintained, as you point out yourself. Writing new code will shortly become more difficult in the 2.x series, as libraries start switching to 3, but the old code will be maintainable for a long while.
In order for the language to keep growing in a clean, pythonic fashion, it needed to be cleaned up a bit, and I think they did a great job of it.
So, I agree with you. But one of Jens' subtexts is, if they're going to clear the deck every 15 years, you might hope for something more interesting than "better Unicode support". There's a lot of stuff that would be nice to have in Python that can't be added without a 3.x-level flag day.
> There's a lot of stuff that would be nice to have in Python that can't be added without a 3.x-level flag day.
that I can definitely agree with.
that I can definitely agree with.
As a sometimes Python core developer allow me to say stuff. The main goal was to remove mistakes; an all-at-once deprecation. The release was actually much less ambitious than the original name "Python 3000" implied. Guido read one of Joel's posts on rewriting software [the one on the Mozilla rewrite] and dictated that 3.0 be done in a year or two. See the list of PEPs [Python Enhancement Proposals] for silly big changes that were shot down.
As for python 3.0 being 10% slower than 2.5 - that means that it is is just 1.9 times faster than Ruby instead of a clean 2x? And the backwards incompatible version took just two years instead of infinity like Perl and two years instead of the UNK for Ruby? Python 2.5 benefited from a corporate sponsored "Need For Speed" sprint where twenty of the core devs went on a paid vacation with a mission to just sprint on speed issues. There hasn't been a corresponding sponsored event for 3.0.
A huge amount of volunteer time has been spent on backwards compatibility issues. When the Python 3.0 issue was first floated the Twisted and Django folks had lots of worries about the transition and supporting two versions (2.x and 3.x). Hundreds of hours were spent on the email lists and PyCon dinners hashing out the details. Thousands of hours were spent adding warnings and best practices docs to 2.6 as well as on the "2to3" translation tool.
Time will tell but there will certainly be lessons learned from the Python 3 release.
As for python 3.0 being 10% slower than 2.5 - that means that it is is just 1.9 times faster than Ruby instead of a clean 2x? And the backwards incompatible version took just two years instead of infinity like Perl and two years instead of the UNK for Ruby? Python 2.5 benefited from a corporate sponsored "Need For Speed" sprint where twenty of the core devs went on a paid vacation with a mission to just sprint on speed issues. There hasn't been a corresponding sponsored event for 3.0.
A huge amount of volunteer time has been spent on backwards compatibility issues. When the Python 3.0 issue was first floated the Twisted and Django folks had lots of worries about the transition and supporting two versions (2.x and 3.x). Hundreds of hours were spent on the email lists and PyCon dinners hashing out the details. Thousands of hours were spent adding warnings and best practices docs to 2.6 as well as on the "2to3" translation tool.
Time will tell but there will certainly be lessons learned from the Python 3 release.
Python3 won't be standard until it's adopted as the main python of several widespread linux distros and available in a clean, batteries included way for OSX and all 36 flavours of windows.
Bitching about py3k is basically whining about being forced to learn new things.
The one question I have is are people going to start using different filename conventions?
I could see temporarily associating .py3 with a /usr/local/bin/py3k for testing purposes and porting 2.6 to 3, but I really hope it doesn't become a widespread practice.
Bitching about py3k is basically whining about being forced to learn new things.
The one question I have is are people going to start using different filename conventions?
I could see temporarily associating .py3 with a /usr/local/bin/py3k for testing purposes and porting 2.6 to 3, but I really hope it doesn't become a widespread practice.
As soon as ActiveState do it, basically. Having identical ActivePython (or ActiveTcl, or even ActivePerl) on all of Solaris, Linux, OSX and Windows just makes things so much easier.
Me, I'm going to yum up those dictionary comprehensions and that OCaml-style pattern matching as soon as I can. Tasty!
Me, I'm going to yum up those dictionary comprehensions and that OCaml-style pattern matching as soon as I can. Tasty!
The ideal approach is "#!/usr/bin/env python3.0".
If you install Python 3 with "make fullinstall" then the binary will be named just "python". I've always used just "#!/usr/bin/env python" and just kept track of what version of Python a collection of code was targeted for. Changing all scripts from "#!/usr/bin/env python3.0" to ""#!/usr/bin/env python3.1" and so on is too cumbersome.
But it depends upon how you manage your code - whether it's just a few loose scripts, part of a larger project, a web app or a desktop app or a command-line script, or what your deployment and install processes looks like, etc. etc. I usually install my Python scripts with Buildout these days, so I let Buildout autogenerate the shebangs to point to the required Python installation.
But it depends upon how you manage your code - whether it's just a few loose scripts, part of a larger project, a web app or a desktop app or a command-line script, or what your deployment and install processes looks like, etc. etc. I usually install my Python scripts with Buildout these days, so I let Buildout autogenerate the shebangs to point to the required Python installation.
That solves one slice of the problem, now how do I distinguish between waycoolscript.py written for python3.0 and waycoolscript.py for python2.4?
I could live with *.py3 for a few years (remember php3?) but it's kind of a wart. And the thing I like about python is the core teams assiduous avoidance of warts.
I could live with *.py3 for a few years (remember php3?) but it's kind of a wart. And the thing I like about python is the core teams assiduous avoidance of warts.
Anyone have any insight on the comment about Python 3 being 10% slower?
It's because they left out a lot of the old optimization hacks when they reworked the interpreter. They'll either be reinserted or better solutions will be found now that the language is stable.
The net result of the 3.0 generalizations is that Python 3.0 runs the pystone benchmark around 10% slower than Python 2.5. Most likely the biggest cause is the removal of special-casing for small integers. There’s room for improvement, but it will happen after 3.0 is released! </quote> http://docs.python.org/3.0/whatsnew/3.0.html
It's a red herring. Py3k is deliberately not a production runtime; it's the "developers and students" release Jens said GvR+co should have released instead of Py3k. Crudding the runtime up with performance hacks would cost more than they'd be worth.
The Ruby comparison Jens makes is exceedingly disingenuous; Ruby 1.9 is a runtime upgrade, not a major language update. Improving performance is mostly the point of it. And even then, there are areas of Ruby that remain controversial, like the threading model.
The Ruby comparison Jens makes is exceedingly disingenuous; Ruby 1.9 is a runtime upgrade, not a major language update. Improving performance is mostly the point of it. And even then, there are areas of Ruby that remain controversial, like the threading model.
From a comment in the article:
> 3.0 is 10% slower because of the change from ints to longs. If you read it carefully, they mention that there is space for improvement, but they want to have it out so people can start to use and see the differences. Release early, release often (and it took 3 years to get there, so better do this once and for all.)
> 3.0 is 10% slower because of the change from ints to longs. If you read it carefully, they mention that there is space for improvement, but they want to have it out so people can start to use and see the differences. Release early, release often (and it took 3 years to get there, so better do this once and for all.)
regular strings now use more than 8 bits per char.
That right there sums up the whole point of Python 3, necessary evil (reverse incompatibility) for future good.