> The syntax evolved, but behind this syntax K&R C behaves in the exact same way, all the way up to the latest C revision. You can't say the same for old vs new classes, which behave in a not so subtly different way, and you can't say that either for the new str/old str, ...
A lot of code operates in a regime where it takes strings as input, attempts to find substrings in those strings based on either pure ASCII literals or other strings also given for input, cuts ranges and substrings out of that string, and then generates more strings as output.
This is in the same way that much of that code was designed so it could accept either an str or a unicode, and as far as I can tell that same code should either work quite fine now taking either a bytes or a str; to the extent to which this is not the case, it could easily be made to be the case.
> ... and indeed you propose a different name, which is perfectly legitimate, as they are different things.
FWIW, I didn't "propose" the new name: "bytes" is the new name: that is what the old str type is now called in Python 3, and in fact if you are using Python 2.7 (even Python 2.6) "bytes" and "str" are aliases for each other, as even the people who designed Python believe they are equivalent for the purposes of portable code. Sadly, without keeping around "unicode" (and preferably just deprecating "str" but leaving it as a warning-laden alias for "bytes") that was pointless.
The reason being that the only place you could actually have compatibility between these types was Python 2.6+... except, most "serious Python" has been stuck in Python 2.5 until possibly (I think I see a sea-change) this year. Yes: that is four years during which these transition mechanisms were largely pointless: neither Python 2.6 nor Python 2.7 were actually deployable targets for major and serious libraries.
Personally, I found this surprising: I have been using Python 2.7 since it came out, and I have never had a difficulty upgrading within Python 2.x. However, time and again when I come across a large company using Python and I ask them "what version?" they say "2.5". Meanwhile, both Jython and App Engine were likewise stuck at that level.
That means to "remain relevant" the primary deployment target for most systems needed to be Python 2.5. The idea of supporting Python 3 or even Python 2.6/7 was largely seen as a hopefully-fun diversion at best, and a needless chore at worst.
Thereby, I will argue that what was really needed was actually not Python 2.7: all of the effort put into Python 2.7 with its support for bridging the gap should have been made to Python 3 in reverse. You can't tell me that supporting some of these things as the same time, at least in ways that make the remaining porting discrepancy "realistic", is possible, as Python 2.7 does it: it is obviously possible, as we have an existence proof.
Now, you can totally (and dalke does) tell me they didn't have time to do that to Python 3, but my argument is that all of the effort exerted into Python 2.7 would have been better spent doing the same thing to Python 3, but with the defaults reversed: I believe that the effort would have comparable, and the result would have been to avoid the last four years of hell.
> The short term cost is that we have a rocky transition and that we won't benefit from the new features right now, while the long term benefit will really be seen 10 years down the road. The question you seem to ask is: will Python still be relevant by then?
This "rocky transition", for people who actually use Python to develop libraries or applications, is simply "stagnation".
One of the things I found so weirdly surprising when I finally decided to "bite the bullet and move back to Java-land" was the amazing number of high-quality maintained libraries for relatively new concepts (even ones so new they were "buzzwords"): it was like a kid suddenly being thrown into a candy store.
Whereas I had spent forever, on numerous occasions, trying to piece together semi-working mechanisms out of multiple competing and seemingly now all disowned or disinterested Python libraries (such as for PDF editing), I suddenly had my pick of numerous fully maintained libraries.
This is not the state of the Python ecosystem when I entered, and I argue that the reason this changed is because of the Python 3 split: the result is that the people still sticking with Python during this "rocky transition" are putting themselves at a "practical" disadvantage for the idea of a "pure" language.
> If not, Python will have paid the price of its 9th zen statement: practicality beats purity.
Right: it seems like that tenant was thrown out the window with respect to the changes made in Python 3.
> Now I will return to the pending migration of three real world ruby 1.8 + rails 2.1 apps to ruby 1.9 + rails 3.2 (and hell was the migration of some other app from python 2.6 to 3.1 so much easier).
Is this difficulty caused by Ruby, however, or by Rails? I had had an application that used Sinatra on 1.8, and it took me about an hour to get it fully compatible with Ruby 1.9 (which I did years ago, at the first opportunity).
(Note: my application was handling Unicode data correctly both before and after change: something that would have been noticed immediately as much of the package information I used was in random languages from Russian to Chinese, and I am quite a stickler for having things encoded correctly in my database; yes: I did have to thwack it some on Ruby 1.8 to get it to work correctly, but the result after thwacking I believe required no modifications on Ruby 1.9, a result that I might argue indicates that most people having porting problems are actually fixing bugs, not porting.)
A lot of code operates in a regime where it takes strings as input, attempts to find substrings in those strings based on either pure ASCII literals or other strings also given for input, cuts ranges and substrings out of that string, and then generates more strings as output.
This is in the same way that much of that code was designed so it could accept either an str or a unicode, and as far as I can tell that same code should either work quite fine now taking either a bytes or a str; to the extent to which this is not the case, it could easily be made to be the case.
> ... and indeed you propose a different name, which is perfectly legitimate, as they are different things.
FWIW, I didn't "propose" the new name: "bytes" is the new name: that is what the old str type is now called in Python 3, and in fact if you are using Python 2.7 (even Python 2.6) "bytes" and "str" are aliases for each other, as even the people who designed Python believe they are equivalent for the purposes of portable code. Sadly, without keeping around "unicode" (and preferably just deprecating "str" but leaving it as a warning-laden alias for "bytes") that was pointless.
The reason being that the only place you could actually have compatibility between these types was Python 2.6+... except, most "serious Python" has been stuck in Python 2.5 until possibly (I think I see a sea-change) this year. Yes: that is four years during which these transition mechanisms were largely pointless: neither Python 2.6 nor Python 2.7 were actually deployable targets for major and serious libraries.
Personally, I found this surprising: I have been using Python 2.7 since it came out, and I have never had a difficulty upgrading within Python 2.x. However, time and again when I come across a large company using Python and I ask them "what version?" they say "2.5". Meanwhile, both Jython and App Engine were likewise stuck at that level.
That means to "remain relevant" the primary deployment target for most systems needed to be Python 2.5. The idea of supporting Python 3 or even Python 2.6/7 was largely seen as a hopefully-fun diversion at best, and a needless chore at worst.
Thereby, I will argue that what was really needed was actually not Python 2.7: all of the effort put into Python 2.7 with its support for bridging the gap should have been made to Python 3 in reverse. You can't tell me that supporting some of these things as the same time, at least in ways that make the remaining porting discrepancy "realistic", is possible, as Python 2.7 does it: it is obviously possible, as we have an existence proof.
Now, you can totally (and dalke does) tell me they didn't have time to do that to Python 3, but my argument is that all of the effort exerted into Python 2.7 would have been better spent doing the same thing to Python 3, but with the defaults reversed: I believe that the effort would have comparable, and the result would have been to avoid the last four years of hell.
> The short term cost is that we have a rocky transition and that we won't benefit from the new features right now, while the long term benefit will really be seen 10 years down the road. The question you seem to ask is: will Python still be relevant by then?
This "rocky transition", for people who actually use Python to develop libraries or applications, is simply "stagnation".
One of the things I found so weirdly surprising when I finally decided to "bite the bullet and move back to Java-land" was the amazing number of high-quality maintained libraries for relatively new concepts (even ones so new they were "buzzwords"): it was like a kid suddenly being thrown into a candy store.
Whereas I had spent forever, on numerous occasions, trying to piece together semi-working mechanisms out of multiple competing and seemingly now all disowned or disinterested Python libraries (such as for PDF editing), I suddenly had my pick of numerous fully maintained libraries.
This is not the state of the Python ecosystem when I entered, and I argue that the reason this changed is because of the Python 3 split: the result is that the people still sticking with Python during this "rocky transition" are putting themselves at a "practical" disadvantage for the idea of a "pure" language.
> If not, Python will have paid the price of its 9th zen statement: practicality beats purity.
Right: it seems like that tenant was thrown out the window with respect to the changes made in Python 3.
> Now I will return to the pending migration of three real world ruby 1.8 + rails 2.1 apps to ruby 1.9 + rails 3.2 (and hell was the migration of some other app from python 2.6 to 3.1 so much easier).
Is this difficulty caused by Ruby, however, or by Rails? I had had an application that used Sinatra on 1.8, and it took me about an hour to get it fully compatible with Ruby 1.9 (which I did years ago, at the first opportunity).
(Note: my application was handling Unicode data correctly both before and after change: something that would have been noticed immediately as much of the package information I used was in random languages from Russian to Chinese, and I am quite a stickler for having things encoded correctly in my database; yes: I did have to thwack it some on Ruby 1.8 to get it to work correctly, but the result after thwacking I believe required no modifications on Ruby 1.9, a result that I might argue indicates that most people having porting problems are actually fixing bugs, not porting.)