Hacker News Reader

Comment by llambda | Hacker News Reader

> if we ever do

No kidding... Here we are, how many years after the release of Python 3? And still, there are many libraries that have yet to be ported to Python 3. These deficiencies make Python 3 an impossible choice for some tasks. The slow adoption of Python 3 is not without reason as many have pointed out, although Armin Ronacher's recent blog post[1] stands out as one of the better illustrations of the frustrations with Python 3. I have to say, as a Pythonista, I am worried about Python. I wonder if things will become increasingly fragmented...

[1] http://lucumr.pocoo.org/2011/12/7/thoughts-on-python3/

View on HN

The adoption rate is expected, people should stop complain about the python3 situation when it's not that bad.

http://sayspy.blogspot.com/2011/01/my-semi-regular-reminder-...

It looks like a patch for Django was just finished relatively recently.

For what it's worth, based on my experience with Ruby 1.8/1.9 in Rails, which is a smaller language change that Py2=>Py3, it will take years and a lot of community work before Django on Python 3 is a plausible solution.

Rails officially supported Ruby 1.9 as early as Rails 2.3 (which was released in February 2009), but a large number of commonly used packages weren't really working for some time after that. Additionally, we made a number of mistakes our initial Ruby 1.9 support (in Rails 2.3), which we corrected in Rails 3.0.

My guess (again, based on my experience with false starts in Rails) is that merging the patch in question will take a while, and that it will require some time after the patch is initially merged before people consider Py3 a valid target for Django apps.

I don't know Ruby, but was the difference between Ruby 1.8 and 1.9 as drastic as the change between Python 2.7 and 3.0? Programs written in Python 3.0 are not backwards compatible. Is it the same with programs written in Ruby 1.9? I'm really asking -- I don't know the answer.

Ruby did us a big favor and made it possible to implement something like Rails in a way that switched between Ruby 1.8 and 1.9 at runtime. There are no changes to the 1.9 parser that cause it to puke on 1.8 syntax.

My understanding is that in Python, you need to use the 2to3 tool for a program of any non-trivial size to have a single codebase that targets both. Please correct me if I'm wrong, as I'm only picking this up by osmosis with the Python community.

Ruby 1.9 is also significantly more runtime compatible with Ruby 1.8 than Python 3 is with Python 2. For example, the object model and semantics for creating classes and object is entirely unchanged between Ruby 1.8 and Ruby 1.9. The Unicode change took great pains to remain compatible with programs using BINARY data for ASCII-only characters, for instance (I personally believe that this was a mistake going forward, but it results in better-than-expected backwards compatibility with Ruby 1.8 programs mixing source code and external ASCII-only data).

As a result, even though Python 3 was released around the same time as Ruby 1.9.1 (the first stable Ruby 1.9 release), the Ruby community is much further along the adoption curve than Python is.

Sorry for the delayed response -- I do want to respond to several points. First, you're sort of correct that you need the 2to3 tool for a program to target Python 2 and Python 3. There are certain programming techniques (such as "from __future__ import *) that will allow you to write you code in such a way that it will run on both Python 2 and 3, although I've not used these on any project of size. But if you wrote your code using plain vanilla 2.x, then you'd need to use the 2to3 tool, although again I've not used it myself and have heard mixed reviews. Unicode is probably the biggest change from Python 2 to 3 that introduces incompatibilities, although I think there are tricks for dealing with that as well. I like Ruby's approach to Unicode based on what you described. Why do you think this is a mistake? I expect you are correct that Ruby is much further along in moving from 1.8 to 1.9, because it sounds like Ruby has handled the upgrade path well (to be honest, I'm not sure Python has).

If you used the ruby 1.9 syntax then it wouldn't be. However, ruby 1.9 still supported the old syntax, so libraries in 1.9 could still be used with 1.8. There wasn't "one right way" to do things in ruby.

Reply on news.ycombinator.com