5 ms·

But what other way there was? It's all about Unicode - it HAS to be resolved at some point, and if what I read is correct than there was no way to make this tra

But what other way there was? It's all about Unicode - it HAS to be resolved at some point, and if what I read is correct than there was no way to make this transition smooth(er). I'm not familiar witr Ruby at all, but I heard there was similar breakage between major versions lately?

saurik 14y ago
The changes were gratuitous, and there were numerous ways of making it happen more smoothly; for an example of a community that handled it much better, just take a look at Ruby 1.9: they have great uptake. To take a really trivial example: the name "str" should not have been reused to mean "unicode", it either should have continued to mean "bytes" or it should have been dropped altogether. Certainly, under no circumstance, should the name "unicode" have been removed, but it was; they also should not have removed the u'' syntax. Their goal wasn't just "fix things" it was "break old things". The result is that it is nearly impossible to write code that runs on both Python 2.x and Python 3.x even when the semantics of the code have absolutely nothing to do with the things people really wanted to change. Another great example of this is the exception syntax: they changed the way you catch exceptions to replace the "," with "as"; less confusing, sure, but again it means that you can't write code that works on both. The answer to this was then a tool "2to3" which smoothed over some of the more obvious problems, but whose entire mission statement was flawed: to keep all code in Python 2, supporting Python 3 as a second-class citizen. A lot of these changes, certainly the syntax ones, could easily have been made per-file: make new scripts .py3 or have a special header, or force old scripts to have a special command line argument or special load path. At least then, you could mix and match new and old code without simply being stuck in the limbo that is Python 2.7... a limbo that didn't even help the cause, as you can't even write fully 2.7/3.x compatible code. The result is that we still have tons of libraries that don't work. When they do, they often have less testing. When they are well tested, they often "took the opportunity" (just like Python itself, which set the bad expectation) to have different semantics, so you have to port your code anyway.
- deleted 14y ago
  [deleted]
- regularfry 14y ago
  I think it's a little unfair to point to Ruby as an example of a community getting it right. The motivation behind the 1.8-to-1.9 shift for a lot of people was the markedly better VM in 1.9 (which is roughly comparable to CPython, as it happens), and not necessarily the language features. Specifically the encoding situation in Ruby 1.9 is... interesting, and easy to find surprising edge cases in.
  - saurik 14y ago
    There is a difference between "right" and "much better" (the term I used). I was able to upgrade my code to use Ruby 1.9 trivially, and the result still worked fine on Ruby 1.8. The transition was downright painless for almost everyone involved. (Disclosure: I am the Jay Freeman mentioned in the thank you at the bottom of Yehuda's article on the Ruby 1.9 encoding changes and how they would and did affect Rails.)
  - TylerE 14y ago
    I think that is sort of the point. There was a carrot (better performance) to go with the stick. Python 3 was pretty much all stick, unless you were a unicode fetishist.
  - dagw 14y ago
    Also Ruby had a far smaller deployment and library base to convert. Get Rails and Sinatra ported and you're mostly there. There are as far as I know no significant commercial software that ships with ruby as its main scripting language. Ruby doesn't really have its equivalent of numpy and friends which has snaked its way into critical software in just about every field you care to mention. Ruby 1.8 -> 1.9 was more like Python 1.X-2.X
- dalke 14y ago
  You are right about the u"" syntax. Thankfully, Python 3.3 supports it again. The "except .. as" clause was backported to Python 2.6, which was released almost 4 years ago. If you don't need to support Python 2.5 then you can migrate to except..as right now. Python 2.6 added "from __future__ import print_function", and so on. The goal was and is to make Python 2.7 a migration to a 3.x. People have and do write code which is usable, and unchanged, in both major version, which seems to contradict your statement that doing so isn't possible. And people continue to work to make that easier, while also advancing Python as a language. Your proposal, to be able to "mix and match new and old code", does not work. At least, not without a lot more development effort behind it. The object models are different enough to make it not work. Remember, Python 2 has both old-style and new-style classes, while Python 3 does not. There's Python 2 code which probably still depends on Python 2 old-style classes, and will break. Which means you're left only being able to support the subset that the Python core developers, and those who wish to become core developers want to support. Which is what we have now.

saurik 14y ago

The changes were gratuitous, and there were numerous ways of making it happen more smoothly; for an example of a community that handled it much better, just take a look at Ruby 1.9: they have great uptake. To take a really trivial example: the name "str" should not have been reused to mean "unicode", it either should have continued to mean "bytes" or it should have been dropped altogether. Certainly, under no circumstance, should the name "unicode" have been removed, but it was; they also should not have removed the u'' syntax. Their goal wasn't just "fix things" it was "break old things". The result is that it is nearly impossible to write code that runs on both Python 2.x and Python 3.x even when the semantics of the code have absolutely nothing to do with the things people really wanted to change. Another great example of this is the exception syntax: they changed the way you catch exceptions to replace the "," with "as"; less confusing, sure, but again it means that you can't write code that works on both. The answer to this was then a tool "2to3" which smoothed over some of the more obvious problems, but whose entire mission statement was flawed: to keep all code in Python 2, supporting Python 3 as a second-class citizen. A lot of these changes, certainly the syntax ones, could easily have been made per-file: make new scripts .py3 or have a special header, or force old scripts to have a special command line argument or special load path. At least then, you could mix and match new and old code without simply being stuck in the limbo that is Python 2.7... a limbo that didn't even help the cause, as you can't even write fully 2.7/3.x compatible code. The result is that we still have tons of libraries that don't work. When they do, they often have less testing. When they are well tested, they often "took the opportunity" (just like Python itself, which set the bad expectation) to have different semantics, so you have to port your code anyway.

deleted 14y ago
[deleted]
regularfry 14y ago
I think it's a little unfair to point to Ruby as an example of a community getting it right. The motivation behind the 1.8-to-1.9 shift for a lot of people was the markedly better VM in 1.9 (which is roughly comparable to CPython, as it happens), and not necessarily the language features. Specifically the encoding situation in Ruby 1.9 is... interesting, and easy to find surprising edge cases in.
- saurik 14y ago
  There is a difference between "right" and "much better" (the term I used). I was able to upgrade my code to use Ruby 1.9 trivially, and the result still worked fine on Ruby 1.8. The transition was downright painless for almost everyone involved. (Disclosure: I am the Jay Freeman mentioned in the thank you at the bottom of Yehuda's article on the Ruby 1.9 encoding changes and how they would and did affect Rails.)
- TylerE 14y ago
  I think that is sort of the point. There was a carrot (better performance) to go with the stick. Python 3 was pretty much all stick, unless you were a unicode fetishist.
- dagw 14y ago
  Also Ruby had a far smaller deployment and library base to convert. Get Rails and Sinatra ported and you're mostly there. There are as far as I know no significant commercial software that ships with ruby as its main scripting language. Ruby doesn't really have its equivalent of numpy and friends which has snaked its way into critical software in just about every field you care to mention. Ruby 1.8 -> 1.9 was more like Python 1.X-2.X
dalke 14y ago
You are right about the u"" syntax. Thankfully, Python 3.3 supports it again. The "except .. as" clause was backported to Python 2.6, which was released almost 4 years ago. If you don't need to support Python 2.5 then you can migrate to except..as right now. Python 2.6 added "from __future__ import print_function", and so on. The goal was and is to make Python 2.7 a migration to a 3.x. People have and do write code which is usable, and unchanged, in both major version, which seems to contradict your statement that doing so isn't possible. And people continue to work to make that easier, while also advancing Python as a language. Your proposal, to be able to "mix and match new and old code", does not work. At least, not without a lot more development effort behind it. The object models are different enough to make it not work. Remember, Python 2 has both old-style and new-style classes, while Python 3 does not. There's Python 2 code which probably still depends on Python 2 old-style classes, and will break. Which means you're left only being able to support the subset that the Python core developers, and those who wish to become core developers want to support. Which is what we have now.