8 ms·

The "Third Way" is to avoid both problems (diverging stable and unstable forks vs. a single line with frequent minor breakage) by making heroic efforts to maint

The "Third Way" is to avoid both problems (diverging stable and unstable forks vs. a single line with frequent minor breakage) by making heroic efforts to maintain backwards compatibility even in the face of major changes. Someone already mentioned Windows as an example of this. I'd point to C++ as another example: the C++ committee's longstanding commitment to maintaining backward compatibility at all costs has always been one of C++'s greatest strengths, and is certainly one of the main reasons why it's still in widespread use despite its age and many flaws.

TylerE 10y ago
The biggest mistake Python 3 made was the print statement change. There was really no compelling reason to do it, it broke basically 2.x script ever for 0 practical gain.
- smcl 10y ago
  I'm not so sure. On one hand yeh sure, print vs print() may not have been something users were clamoring for, or worth adding an additional layer of confusion/weirdness over. However it's relatively straight-forward to port such code or instruct someone "ah you don't do print x you do print(x)". From what I've seen the unicode/string bytes/chars is a much bigger factor. Ironically this change made my largest Python app easier in Python 3 (easier to embed unicode literals from various languages), so perhaps my opinion isn't so valid here...
  - TylerE 10y ago
    The unicode change was more impactful, but the print was more like a little fuck you to maintenance devs everywhere. If they wanted print-as-function, fine, but they didn't have to eliminate the print statement at the same time. Some warts you're better off not scratching at.
    - guitarbill 10y ago
      >> There was really no compelling reason to do it > the print was more like a little fuck you to maintenance devs everywhere > If they wanted print-as-function, fine, but they didn't have to eliminate the print statement at the same time. Complete and utter hyperbole. You could read PEP-3105 [0] and easily see it isn't true. In addition to this, quoting from both the PEP and the docs [0][1]: > "Luckily, as it is a statement in Python 2, print can be detected and replaced reliably and non-ambiguously by an automated tool, so there should be no major porting problems (provided someone writes the mentioned tool)." > "When using the 2to3 source-to-source conversion tool, all print statements are automatically converted to print() function calls, so this is mostly a non-issue for larger projects." Enough with the bullshit. [0] https://www.python.org/dev/peps/pep-3105/ https://www.python.org/dev/peps/pep-3105/ [1] https://docs.python.org/3/whatsnew/3.0.html https://docs.python.org/3/whatsnew/3.0.html
      - hartator 10y ago
        At the end of day, if enough people beleive print requiring brakets is an issue, it's becoming an issue. I beleive it and few other people beleive it in this thread. There is no added benefits to have done that. They are just not listening. Now, Pythons 2/3 are sufferin despite being one of best language out there.
        guitarbill 10y ago
        > There is no added benefits to have done that. For god's sake, it is subtle, but not that hard to understand. There are added benefits. For one thing, consistency. Why is `sys.stdin.write()` a function but `print` isn't? What happens if you want to replace `print` with your own function, e.g. for logging? With a print function, you can just reassign that function, with a statement, you can't. What's the effect of this switch on the bytecode/parsing code? All the arguments against it seem to come down to "I don't like it". > being one of best language out there. Why is Python one of the best languages out there? Ease of use through consistency. Surely that's just an argument for `print()`. Python3 allowed the devs to fix some of the mistakes or sins of the past, similarly `input`/`raw_input`. In the short term, it's maybe a bit of hassle. In the long run, not at all. 2to3 handles this mostly, but you can use `from __future__ import print_function` to test it in Python2. Nobody is refusing to switch to Python3 because of `print` alone.
  - anoctopus 10y ago
    Sure it's easy to fix, but it made a ton of scripts stop working despite being otherwise unaffected by the version change, all for the sake of a small syntax change. Unicode strings are a much bigger change and required some effort to fix, but it improved the language semantics while the print change rendered lots of scripts incompatible for no good reason. Just deprecating the old syntax and giving tons of warnings for a while before dropping it would have been much better.
    - smcl 10y ago
      I totally get you and I genuinely agree, it probably wasn't something so important to risk pissing people off over. As the sister comment to yours mentioned it could be seen as a bit of a "fuck you" to maintenance devs, but if we're honest with ourselves the reason that people haven't moved to Python 3.x after 7+ years isn't really due to print(). edit: sorry I hit "flag" instead of "parent" when trying to navigate back, hope that didn't affect anything (I've since unflagged)
      - TylerE 10y ago
        Ultimately, I think Python 3 had exactly the wrong amount of breakage. They either should have broken way less (e.g., let 2.x code run largely unchanged if it didn't deal closely with unicode) or should have broken more, to give more of carrot... like if some of the new async stuff could have been available in 3.0, that would have given some people a reason to move right away.
        freehunter 10y ago
        I kind of feel like that's why print changed. It's going to be used in almost every Python script at some point in time, so it forces a breaking change without causing a seriously major break by itself. It's enough to make your script need to be updated, but not enough to make you re-write it from scratch (possibly in another language).
  - zodiac 10y ago
    The concepts of "text" and "array of bytes" should have been separated from the beginning, as they're distinct enough concepts. It's good that they separated them in python 3 but unfortunate that it causes problems because code didn't explicitly distinguish these two concepts.
Yokohiii 10y ago
Well no one wants to hear it, but PHP devs do a good job keeping BC breaks minimal.
- wvenable 10y ago
  PHP4 to PHP5 was almost as big of a deal as Python2 to Python3. In fact, while I have PHP5 code that can easily ported to PHP7 -- I still have PHP4 code that will be forever on PHP4. Because of this, PHP developers strive to avoid this kind of large breakage. Instead it's a smooth stream of deprecation and removals/changes and really large changes (like native unicode strings) have been non-starters.
  - gkop 10y ago
    I might be misguided, but the last time I used PHP was over ten years ago, using PHP3, and we had to name the files my_file.php3 in order to use PHP3. That's the opposite of minimal breakage. On the other hand, my simple PHP3 scripts continue to work to this day, php3 extension and all!
    - wvenable 10y ago
      That's just how your server was/is configured.
- fygdttysf 10y ago
  As far as languages go, it broke a lot. Not that it shouldn't have (register_globals) but it was obvious they were learning on the job. You can't run most PHP3 code nowadays without work.
  - spdionis 10y ago
    It's more like after PHP 5 the community had learned that lesson, while python didn't have the chance yet. Given that, I think the PHP community handled the split much better, with the FIG pushing hard for PHP 5. I think the difference is that most of PHP install base was managed by third parties (hosting providers) and once you lobbied those you basically forced everyone to upgrade. With python most of the install base is proprietary, and thus more fragmented, which makes it much more complicated to lobby for an upgrade.
atmosx 10y ago
I'm not sure if there's a third way for software that is omnipresent as Python. Usually you have libraries, etc. which might be developed or not. As technology progresses, you can't achieve 100% backwards compatibility... I mean it's an accident waiting to happen, it's not a case of if it's just a case of when and how.
Too 10y ago
Imo c++ is terrible because of trying to maintain backwards compatibility too hard. Sure, keep abi and linking compatibility all you want but why should I be able to compile code written for c++98 in c++17 mode? No corporate policy would allow you to just flip the switch without thorough review and regression testing anyway. Removing features is also a feature. It would be better if you could compile each library in a different mode but still allow them to link to each other, this would allow you to gradually write code without the old crap in new libraries and still keep proven old code untouched.

TylerE 10y ago

The biggest mistake Python 3 made was the print statement change. There was really no compelling reason to do it, it broke basically 2.x script ever for 0 practical gain.

smcl 10y ago
I'm not so sure. On one hand yeh sure, print vs print() may not have been something users were clamoring for, or worth adding an additional layer of confusion/weirdness over. However it's relatively straight-forward to port such code or instruct someone "ah you don't do print x you do print(x)". From what I've seen the unicode/string bytes/chars is a much bigger factor. Ironically this change made my largest Python app easier in Python 3 (easier to embed unicode literals from various languages), so perhaps my opinion isn't so valid here...
- TylerE 10y ago
  The unicode change was more impactful, but the print was more like a little fuck you to maintenance devs everywhere. If they wanted print-as-function, fine, but they didn't have to eliminate the print statement at the same time. Some warts you're better off not scratching at.
  - guitarbill 10y ago
    >> There was really no compelling reason to do it > the print was more like a little fuck you to maintenance devs everywhere > If they wanted print-as-function, fine, but they didn't have to eliminate the print statement at the same time. Complete and utter hyperbole. You could read PEP-3105 [0] and easily see it isn't true. In addition to this, quoting from both the PEP and the docs [0][1]: > "Luckily, as it is a statement in Python 2, print can be detected and replaced reliably and non-ambiguously by an automated tool, so there should be no major porting problems (provided someone writes the mentioned tool)." > "When using the 2to3 source-to-source conversion tool, all print statements are automatically converted to print() function calls, so this is mostly a non-issue for larger projects." Enough with the bullshit. [0] https://www.python.org/dev/peps/pep-3105/ https://www.python.org/dev/peps/pep-3105/ [1] https://docs.python.org/3/whatsnew/3.0.html https://docs.python.org/3/whatsnew/3.0.html
    - hartator 10y ago
      At the end of day, if enough people beleive print requiring brakets is an issue, it's becoming an issue. I beleive it and few other people beleive it in this thread. There is no added benefits to have done that. They are just not listening. Now, Pythons 2/3 are sufferin despite being one of best language out there.
      - guitarbill 10y ago
        > There is no added benefits to have done that. For god's sake, it is subtle, but not that hard to understand. There are added benefits. For one thing, consistency. Why is `sys.stdin.write()` a function but `print` isn't? What happens if you want to replace `print` with your own function, e.g. for logging? With a print function, you can just reassign that function, with a statement, you can't. What's the effect of this switch on the bytecode/parsing code? All the arguments against it seem to come down to "I don't like it". > being one of best language out there. Why is Python one of the best languages out there? Ease of use through consistency. Surely that's just an argument for `print()`. Python3 allowed the devs to fix some of the mistakes or sins of the past, similarly `input`/`raw_input`. In the short term, it's maybe a bit of hassle. In the long run, not at all. 2to3 handles this mostly, but you can use `from __future__ import print_function` to test it in Python2. Nobody is refusing to switch to Python3 because of `print` alone.
- anoctopus 10y ago
  Sure it's easy to fix, but it made a ton of scripts stop working despite being otherwise unaffected by the version change, all for the sake of a small syntax change. Unicode strings are a much bigger change and required some effort to fix, but it improved the language semantics while the print change rendered lots of scripts incompatible for no good reason. Just deprecating the old syntax and giving tons of warnings for a while before dropping it would have been much better.
  - smcl 10y ago
    I totally get you and I genuinely agree, it probably wasn't something so important to risk pissing people off over. As the sister comment to yours mentioned it could be seen as a bit of a "fuck you" to maintenance devs, but if we're honest with ourselves the reason that people haven't moved to Python 3.x after 7+ years isn't really due to print(). edit: sorry I hit "flag" instead of "parent" when trying to navigate back, hope that didn't affect anything (I've since unflagged)
    - TylerE 10y ago
      Ultimately, I think Python 3 had exactly the wrong amount of breakage. They either should have broken way less (e.g., let 2.x code run largely unchanged if it didn't deal closely with unicode) or should have broken more, to give more of carrot... like if some of the new async stuff could have been available in 3.0, that would have given some people a reason to move right away.
      - freehunter 10y ago
        I kind of feel like that's why print changed. It's going to be used in almost every Python script at some point in time, so it forces a breaking change without causing a seriously major break by itself. It's enough to make your script need to be updated, but not enough to make you re-write it from scratch (possibly in another language).
- zodiac 10y ago
  The concepts of "text" and "array of bytes" should have been separated from the beginning, as they're distinct enough concepts. It's good that they separated them in python 3 but unfortunate that it causes problems because code didn't explicitly distinguish these two concepts.

Yokohiii 10y ago

Well no one wants to hear it, but PHP devs do a good job keeping BC breaks minimal.

wvenable 10y ago
PHP4 to PHP5 was almost as big of a deal as Python2 to Python3. In fact, while I have PHP5 code that can easily ported to PHP7 -- I still have PHP4 code that will be forever on PHP4. Because of this, PHP developers strive to avoid this kind of large breakage. Instead it's a smooth stream of deprecation and removals/changes and really large changes (like native unicode strings) have been non-starters.
- gkop 10y ago
  I might be misguided, but the last time I used PHP was over ten years ago, using PHP3, and we had to name the files my_file.php3 in order to use PHP3. That's the opposite of minimal breakage. On the other hand, my simple PHP3 scripts continue to work to this day, php3 extension and all!
  - wvenable 10y ago
    That's just how your server was/is configured.
fygdttysf 10y ago
As far as languages go, it broke a lot. Not that it shouldn't have (register_globals) but it was obvious they were learning on the job. You can't run most PHP3 code nowadays without work.
- spdionis 10y ago
  It's more like after PHP 5 the community had learned that lesson, while python didn't have the chance yet. Given that, I think the PHP community handled the split much better, with the FIG pushing hard for PHP 5. I think the difference is that most of PHP install base was managed by third parties (hosting providers) and once you lobbied those you basically forced everyone to upgrade. With python most of the install base is proprietary, and thus more fragmented, which makes it much more complicated to lobby for an upgrade.

atmosx 10y ago

I'm not sure if there's a third way for software that is omnipresent as Python. Usually you have libraries, etc. which might be developed or not. As technology progresses, you can't achieve 100% backwards compatibility... I mean it's an accident waiting to happen, it's not a case of if it's just a case of when and how.

Too 10y ago

Imo c++ is terrible because of trying to maintain backwards compatibility too hard. Sure, keep abi and linking compatibility all you want but why should I be able to compile code written for c++98 in c++17 mode? No corporate policy would allow you to just flip the switch without thorough review and regression testing anyway. Removing features is also a feature. It would be better if you could compile each library in a different mode but still allow them to link to each other, this would allow you to gradually write code without the old crap in new libraries and still keep proven old code untouched.