Python 3.0: What's The Point?

http://mooseyard.com/Jens/2008/12/python-30-whats-the-point/

by twampss • 18 years ago

17 32 18 years ago

bdfh424• 18 years ago

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.

jimbokun• 18 years ago

I think, though, a number of programmers did leave Visual Basic for other things over those changes. Is that not correct?

giardini2• 18 years ago

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.

bdfh424• 18 years ago

I think the stats show that VB.NET is the most popular .NET language - so I think we are talking many more than thousands.

gaius3• 18 years ago

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.

Freaky• 18 years ago

Isn't VB.NET lots faster than VB by virtue of targeting a fully blown JITing VM? That's a damn good "yes, but".

gaius3• 18 years ago

No, regular VB6 was compiled.

ninjackn• 18 years ago

According to the Zen of Python (http://www.python.org/dev/peps/pep-0020/), and the whole idea upon which python is created: "There should be one-- and preferably only one --obvious way to do it."

That right there sums up the whole point of Python 3, necessary evil (reverse incompatibility) for future good.

gcheong• 18 years ago

Anyone have any insight on the comment about Python 3 being 10% slower?

jmtulloss• 18 years ago

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.

newsycaccount• 18 years ago

regular strings now use more than 8 bits per char.

d0mine• 18 years ago

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

gasull• 18 years ago

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.)

tptacek5• 18 years ago

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.

zapadoo2• 18 years ago

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.

tptacek5• 18 years ago

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?

zapadoo2• 18 years ago

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.

olefoo2• 18 years ago

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.

Rhamphoryncus• 18 years ago

The ideal approach is "#!/usr/bin/env python3.0".

kteague• 18 years ago

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.

olefoo2• 18 years ago

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.

gaius3• 18 years ago

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!

tptacek5• 18 years ago

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.

llimllib3• 18 years ago

"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.

tptacek5• 18 years ago

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.

jackdied• 18 years ago

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.

Python 3.0: What's The Point?

Related Stories