Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Python 3.0: What's The Point?

mooseyard.com

Post reply on HN
Print view View original

21–30 of 33 posts

Re: Python 3.0: What's The Point?

#21

Post by tptacek »

gcheong wrote: post #6

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

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.

Re: Python 3.0: What's The Point?

#22

Post by tptacek »

zapadoo wrote: post #8

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 en…

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?

Re: Python 3.0: What's The Point?

#23

Post by tptacek »

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.

Re: Python 3.0: What's The Point?

#24

Post by llimllib »

tptacek wrote: post #23

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'…

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

Re: Python 3.0: What's The Point?

#25

Post by zapadoo »

tptacek wrote: post #22
zapadoo wrote: post #8

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 en…

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.

Re: Python 3.0: What's The Point?

#26

Post by tptacek »

llimllib wrote: post #24
tptacek wrote: post #23

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'…

"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-st…

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.

Re: Python 3.0: What's The Point?

#27

Post by llimllib »

tptacek wrote: post #26
llimllib wrote: post #24

Earlier quoted context omitted.

"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-st…

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 lib…

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

Re: Python 3.0: What's The Point?

#28

Post by tptacek »

llimllib wrote: post #27
tptacek wrote: post #26

Earlier quoted context omitted.

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 lib…

> 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 uni…

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.

Re: Python 3.0: What's The Point?

#29

Post by llimllib »

tptacek wrote: post #28
llimllib wrote: post #27

Earlier quoted context omitted.

> 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 uni…

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.

Re: Python 3.0: What's The Point?

#30

Post by jackdied »

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.

Post reply on HN