4 ms·

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

by wycats 15y ago

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.

jnbiche 15y ago
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).

by wycats 15y ago

jnbiche 15y ago

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