3 ms·

> gets ... backwards compatibility That should be past tense, "got" as the Python community has certainly learned its lesson. Luckily it wasn't as bad a mistak

> gets ... backwards compatibility That should be past tense, "got" as the Python community has certainly learned its lesson. Luckily it wasn't as bad a mistake as the Perl folks made.

jacquesm 11y ago
> That should be past tense, "got" as the Python community has certainly learned its lesson. Evidence of that to me would be a proposed fix and maybe I'm too out of touch with what's happening in the python world but from what I see the two main version still co-exist rather than that any attempt at unification has been made. Am I missing something major here? My understanding is that you migrate your project to 3.x or you're stuck in the past. > Luckily it wasn't as bad a mistake as the Perl folks made. That's up for debate.
- kzrdude 11y ago
  It sounds like you are still in the Denial phase?
  - jacquesm 11y ago
    No, I'm just lucky that I don't actually need anything that 3.x has to offer. The python code I wrote uses a bunch of modules that are not available for 3.x so that's one reason for being stuck (and they won't be ported either and I don't feel like doing it myself). The old code works and works well enough that I just set it up in a VM where it will happily work for decades to come. New stuff gets written in other languages, once burned, twice shy. I loved the way I could use python to quickly prototype some GUI based program, but I don't love it that much over that I can't write the same program in a wide choice of different languages with other ideas about long term stability.
    - msellout 11y ago
      Before the tragedy of the Perl 5-6 transition, I don't think people realized how important backwards compatibility is. I understand your fear, but perhaps the most reliable team is the one that's already made the mistake and been burned.
- nostrademons 11y ago
  Python 2 and Python 3 are different languages. The core Python team is working exclusively on Python 3. If you're using Python 2, you're using a deprecated language, with all the pitfalls that entails. It's much like using Visual Basic or Delphi in the mid-2000s: you can do it, you can build some fairly decent applications quite productively, but you aren't going to get any improvements in the future and you're not going to be at the leading edge of technology.
- msellout 11y ago
  Yes, you are missing that the str as bytes to str as Unicode transition was a tough problem. That's the major incompatibility. Once that decision (mistake?) was made, the break was irrevocable. Perhaps not in theory, but in the practice of how Python 2 folks have used strs.
  - raiph 11y ago
    Aiui the Unicode problem is even more complex than most folk realize for the reasons I explain in this comment. ----------------------------------------- On the final technical destination implied by Unicode: The final technical destination implied by the Unicode standard is correct handling of "grapheme clusters".[1] ----------------------------------------- On the half way point at which we've arrived: In the 80s, there were a bazillion incompatible "character" sets and encodings of those "character" sets. Unicode was a response to this. The half way point envisaged by the original Unicode design was to firmly establish a single overall "character set" view with a handful of encodings. Imo we've arrived at this half way point. ----------------------------------------- On the string types of languages: Programming languages designed before Unicode emerged adopted the "byte=character" view to determine the character unit of their default string type, leaving higher level views to library code and functions. This is the level Python began at. But the more established Unicode becomes, the more important the higher level views become. Newer languages have mostly been designed to optimize for Unicode's half way point (but not the eventual destination). They typically support the byte view in some form but adopt the "codepoint=character" view to determine the character unit of their default string type. Aiui, this is where Python 3 is at. A handful of newer languages continue to support the byte and codepoint views in some form but have adopted the highest level "grapheme=character" view for the character unit of their default string type. I think the most visible new language that's been forward-thinking enough to adopt the final destination view (grapheme=character) is Swift. ----------------------------------------- [1] Folks trying to understand this point should find it helpful to start with the deceptively brief hint inherent in http://www.unicode.org/glossary/#Grapheme http://www.unicode.org/glossary/#Grapheme which defines "what a user thinks of as a character". Next, I'll quote the perluniintro[2] document: > A Unicode logical "character" can actually consist of more than one internal actual "character" or code point. For Western languages, this is adequately modelled by a base character (like LATIN CAPITAL LETTER A ) followed by one or more modifiers (like COMBINING ACUTE ACCENT ). This sequence of base character and modifiers is called a combining character sequence. Some non-western languages require more complicated models, so Unicode created the grapheme cluster concept, which was later further refined into the extended grapheme cluster. [2] http://perldoc.perl.org/perluniintro.html http://perldoc.perl.org/perluniintro.html

> gets ... backwards compatibility That should be past tense, "got" as the Python community has certainly learned its lesson. Luckily it wasn't as bad a mistake as the Perl folks made.

jacquesm 11y ago

> That should be past tense, "got" as the Python community has certainly learned its lesson. Evidence of that to me would be a proposed fix and maybe I'm too out of touch with what's happening in the python world but from what I see the two main version still co-exist rather than that any attempt at unification has been made. Am I missing something major here? My understanding is that you migrate your project to 3.x or you're stuck in the past. > Luckily it wasn't as bad a mistake as the Perl folks made. That's up for debate.

kzrdude 11y ago
It sounds like you are still in the Denial phase?
- jacquesm 11y ago
  No, I'm just lucky that I don't actually need anything that 3.x has to offer. The python code I wrote uses a bunch of modules that are not available for 3.x so that's one reason for being stuck (and they won't be ported either and I don't feel like doing it myself). The old code works and works well enough that I just set it up in a VM where it will happily work for decades to come. New stuff gets written in other languages, once burned, twice shy. I loved the way I could use python to quickly prototype some GUI based program, but I don't love it that much over that I can't write the same program in a wide choice of different languages with other ideas about long term stability.
  - msellout 11y ago
    Before the tragedy of the Perl 5-6 transition, I don't think people realized how important backwards compatibility is. I understand your fear, but perhaps the most reliable team is the one that's already made the mistake and been burned.
nostrademons 11y ago
Python 2 and Python 3 are different languages. The core Python team is working exclusively on Python 3. If you're using Python 2, you're using a deprecated language, with all the pitfalls that entails. It's much like using Visual Basic or Delphi in the mid-2000s: you can do it, you can build some fairly decent applications quite productively, but you aren't going to get any improvements in the future and you're not going to be at the leading edge of technology.
msellout 11y ago
Yes, you are missing that the str as bytes to str as Unicode transition was a tough problem. That's the major incompatibility. Once that decision (mistake?) was made, the break was irrevocable. Perhaps not in theory, but in the practice of how Python 2 folks have used strs.
- raiph 11y ago
  Aiui the Unicode problem is even more complex than most folk realize for the reasons I explain in this comment. ----------------------------------------- On the final technical destination implied by Unicode: The final technical destination implied by the Unicode standard is correct handling of "grapheme clusters".[1] ----------------------------------------- On the half way point at which we've arrived: In the 80s, there were a bazillion incompatible "character" sets and encodings of those "character" sets. Unicode was a response to this. The half way point envisaged by the original Unicode design was to firmly establish a single overall "character set" view with a handful of encodings. Imo we've arrived at this half way point. ----------------------------------------- On the string types of languages: Programming languages designed before Unicode emerged adopted the "byte=character" view to determine the character unit of their default string type, leaving higher level views to library code and functions. This is the level Python began at. But the more established Unicode becomes, the more important the higher level views become. Newer languages have mostly been designed to optimize for Unicode's half way point (but not the eventual destination). They typically support the byte view in some form but adopt the "codepoint=character" view to determine the character unit of their default string type. Aiui, this is where Python 3 is at. A handful of newer languages continue to support the byte and codepoint views in some form but have adopted the highest level "grapheme=character" view for the character unit of their default string type. I think the most visible new language that's been forward-thinking enough to adopt the final destination view (grapheme=character) is Swift. ----------------------------------------- [1] Folks trying to understand this point should find it helpful to start with the deceptively brief hint inherent in http://www.unicode.org/glossary/#Grapheme http://www.unicode.org/glossary/#Grapheme which defines "what a user thinks of as a character". Next, I'll quote the perluniintro[2] document: > A Unicode logical "character" can actually consist of more than one internal actual "character" or code point. For Western languages, this is adequately modelled by a base character (like LATIN CAPITAL LETTER A ) followed by one or more modifiers (like COMBINING ACUTE ACCENT ). This sequence of base character and modifiers is called a combining character sequence. Some non-western languages require more complicated models, so Unicode created the grapheme cluster concept, which was later further refined into the extended grapheme cluster. [2] http://perldoc.perl.org/perluniintro.html http://perldoc.perl.org/perluniintro.html