5 ms·

The problem is why should people be "converting the mess" in the first place. Backward compatibility, especially when it comes to programming languages, should

by disown 6y ago

The problem is why should people be "converting the mess" in the first place. Backward compatibility, especially when it comes to programming languages, should be a given. If anything, this is reason that people should stop using python.

mkoubaa 6y ago
Python is FOSS. If there was a big enough market for python 2 it would have been forked and maintained by a separate entity. That it didn't happen proves this is overblown
- heavyset_go 6y ago
  There are entities out there with support contracts that stipulate Python 2 support for a while. Red Hat is one such entity[1]. [1] https://access.redhat.com/solutions/4455511 https://access.redhat.com/solutions/4455511
- deleted 6y ago
  [deleted]
- atoav 6y ago
  I guess there isn't really a propper need for a perpetuation of python27. This is mostly people who don't really see a difference between the versions other than that their print statements suddenly fail or that unmaintained dependency they used in that code half a decade ago complains. Who cares about the security pitfalls involved with using outdated python when tour code doesn't work? Of course python could have dealt better with backwards compatibility, but the python code I wrote was transfered to version 3 pretty quickly.
- stock_toaster 6y ago
  > If there was a big enough market for python 2 it would have been forked and maintained by a separate entity. Perhaps some chose instead move to other languages.
- Jasper_ 6y ago
  It happened multiple times, and one of the times, the project needed to be renamed, causing a huge argument, lots of eyes on the project, and momentum to slow. There's a huge social cost to a fork. https://github.com/naftaliharris/tauthon/issues/47 https://github.com/naftaliharris/tauthon/issues/47
tayo42 6y ago
Is there really that much choice for alternatives though? What else is installed everywhere, has a repl, huge standard library and tons of learning resources, no boilerplate to get going. I don't really like python and still consistently find uses for it.
- abhorrence 6y ago
  Ruby meets most of those criteria. It also had a more graceful (though not without its pains) Unicode transition, as it allowed you to mark file by file the status of string literals.
  - takeda 6y ago
    Ruby is a comical example, because they did breaking changes in minor version (I think it was 1.8 to 1.9?). The thing I think they did better though, is they didn't give people 10 years to fix their sh*t. You either moved on or you stayed with an unsupported version, and people did move on. For Python 3 the major shifts were in 2015 and 2020. The first year was when PSF announced they won't add any new features to 2.7, and that's when libraries started adding Python 3 support. And 2020 was EOL for Python 2.7. It doesn't matter how much time you give people to migrate, they will always do it at the very last minute.
    - p_l 6y ago
      The amount of breaking changes was also much smaller than in Py3k. Also, 1.8 marked the creation of complete compliance test suite (as Ruby 1.8 became an ISO Standard), and that test suite has been expanded since then allowing for alternative implementations. Because the test suite is your target, not a hard to interpret 2kLOC spaghetti code C function.
    - dragonwriter 6y ago
      > Ruby is a comical example, because they did breaking changes in minor version (I think it was 1.8 to 1.9?). Ruby was then using a version numbering scheme similar to the old Linux version numbering scheme, where odd minor numbers were development releases and even minor numbers were stable releases. In that scheme a odd minor version is equivalent to a SemVer major release. (Ruby switched to SemVer-ish versions with 2.x)
Barrin92 6y ago
Categorically demanding complete backward compatibility puts huge limitations on the development of the language. I agree that the barrier should be high, and I don't think many disagree that the Python transition was a mess, but for languages to evolve there needs to at least be some way to fix issues that are considered design errors. There's no optimal or blameless solution here but I think in particular when it comes to the scientist use-case mentioned above, an entire decade is enough to address what is likely a relatively small codebase, it's not just a fault of the language, but also neglect or lack of resources in fields where programming is secondary in nature. (also btw detrimental to the quality of science, as recent cases have shown where programming errors basically invalidated entire studies)
- dTal 6y ago
  >Categorically demanding complete backward compatibility puts huge limitations on the development of the language Not really. Just introduce an optional version declaration at the top of the file, which guarantees the old behavior. Then feel free to tinker with the design as much as you want. It's a solved problem and it works well. Sure, you still break people's code if they don't put a version declaration in - but now the fix is a single line. The fatal flaw in Python's approach was cleaving apart the Python2 and Python3 worlds, making it impossible to mutually import modules. Python2 and Python3 are practically speaking different languages - different syntax, different semantics, different libraries, and a different userbase. As far as the computer is concerned, they are separate entities, with the feeble "2to3" program being the only thing linking them.
  - takeda 6y ago
    Actually I did some small tests, and you could mix python2 and python3 code together through use of Cython. You can use Cython to compile your python 2 code into .so objects and then include them in Python 3. Then you can progressively migrate code file by file to Python 3. I didn't do it on a larger project, so maybe there are some gotchas, but it seems to work as far as I could test it. Regarding the differences in languages Python 2.7 was actually a bridge to migrate to Python 3. That's why all features of 2.7 were backported from 3 (this was also the reason people saying: "why should I migrate to 3, it doesn't offere anything new". It didn't because everything new was backported. Anyway thanks to this it was actually possible to write code that worked on both Python version. I did it several times. It was actually the easiest when you wrote the code for Python 3 and only used features that 2 had. Add all the `__future__` imports and remaining parts filled with the `six` module.
bartread 6y ago
> If anything, this is reason that people should stop using python. It's also the reason I never started in the first place. It wasn't in any way clear which the right option was during the period of schism, and it went on for an awfully long time. With that being said I'm starting to tinker with Python now simply because it has a great ecosystem for NLP and ML. I certainly need the former, although how much of the latter I'll need (possibly none) is unclear. Regardless, it seems to be the de facto standard language for anything that falls under the broad category of data science to the point where for me to pick up a different language would feel very much like swimming upstream.
the__alchemist 6y ago
I'd like to follow this to its logical conclusion: Are you suggesting that it's desirable to make a new language vice improving an old one? (Related, but separate:) Would you have preferred if Python 3 was released under a different name that didn't include "python"?
- xapata 6y ago
  No, they should have made the breaking changes more slowly, piece by piece, with a couple minor versions depreciation cycle. Python 3 was too many changes simultaneously. But it also coincided with dramatic changes in the size and variety of the programming community. It was hard to anticipate the troubles, of course easy in hindsight.
- Wowfunhappy 6y ago
  Yes, if you're going to break compatibility to a great enough extent. It would eliminate an immense amount of confusion. See what Perl did with Raku.
- donor20 6y ago
  You fail to understand that they purposely broke compatibility for no benefit. That is not improving the language - that is being stupid. In python 2 you could specify a unicode literal with u''. So a natural evolutionary option if you had a unicode addiction and wanted python 3 to be unicode native, would be to treat u'' as unicode literals in python 3 as well. This let's the code run under python 2 still, and then you get unicode in 3. And if you are 3 only, just "blah blah" works as well - nice. But they didn't do that. They purposely took u'' out to make it hard to support 2 and 3. That is absolute stupidity. In other words, they BROKE compatibility for no benefit - but just to break it. They did the same thing with byte handling, jumped the io abstraction in - these things all destroyed performance and use cases.

by disown 6y ago

mkoubaa 6y ago

Python is FOSS. If there was a big enough market for python 2 it would have been forked and maintained by a separate entity. That it didn't happen proves this is overblown

heavyset_go 6y ago
There are entities out there with support contracts that stipulate Python 2 support for a while. Red Hat is one such entity[1]. [1] https://access.redhat.com/solutions/4455511 https://access.redhat.com/solutions/4455511
deleted 6y ago
[deleted]
atoav 6y ago
I guess there isn't really a propper need for a perpetuation of python27. This is mostly people who don't really see a difference between the versions other than that their print statements suddenly fail or that unmaintained dependency they used in that code half a decade ago complains. Who cares about the security pitfalls involved with using outdated python when tour code doesn't work? Of course python could have dealt better with backwards compatibility, but the python code I wrote was transfered to version 3 pretty quickly.
stock_toaster 6y ago
> If there was a big enough market for python 2 it would have been forked and maintained by a separate entity. Perhaps some chose instead move to other languages.
Jasper_ 6y ago
It happened multiple times, and one of the times, the project needed to be renamed, causing a huge argument, lots of eyes on the project, and momentum to slow. There's a huge social cost to a fork. https://github.com/naftaliharris/tauthon/issues/47 https://github.com/naftaliharris/tauthon/issues/47

tayo42 6y ago

Is there really that much choice for alternatives though? What else is installed everywhere, has a repl, huge standard library and tons of learning resources, no boilerplate to get going. I don't really like python and still consistently find uses for it.

abhorrence 6y ago
Ruby meets most of those criteria. It also had a more graceful (though not without its pains) Unicode transition, as it allowed you to mark file by file the status of string literals.
- takeda 6y ago
  Ruby is a comical example, because they did breaking changes in minor version (I think it was 1.8 to 1.9?). The thing I think they did better though, is they didn't give people 10 years to fix their sh*t. You either moved on or you stayed with an unsupported version, and people did move on. For Python 3 the major shifts were in 2015 and 2020. The first year was when PSF announced they won't add any new features to 2.7, and that's when libraries started adding Python 3 support. And 2020 was EOL for Python 2.7. It doesn't matter how much time you give people to migrate, they will always do it at the very last minute.
  - p_l 6y ago
    The amount of breaking changes was also much smaller than in Py3k. Also, 1.8 marked the creation of complete compliance test suite (as Ruby 1.8 became an ISO Standard), and that test suite has been expanded since then allowing for alternative implementations. Because the test suite is your target, not a hard to interpret 2kLOC spaghetti code C function.
  - dragonwriter 6y ago
    > Ruby is a comical example, because they did breaking changes in minor version (I think it was 1.8 to 1.9?). Ruby was then using a version numbering scheme similar to the old Linux version numbering scheme, where odd minor numbers were development releases and even minor numbers were stable releases. In that scheme a odd minor version is equivalent to a SemVer major release. (Ruby switched to SemVer-ish versions with 2.x)

Barrin92 6y ago

Categorically demanding complete backward compatibility puts huge limitations on the development of the language. I agree that the barrier should be high, and I don't think many disagree that the Python transition was a mess, but for languages to evolve there needs to at least be some way to fix issues that are considered design errors. There's no optimal or blameless solution here but I think in particular when it comes to the scientist use-case mentioned above, an entire decade is enough to address what is likely a relatively small codebase, it's not just a fault of the language, but also neglect or lack of resources in fields where programming is secondary in nature. (also btw detrimental to the quality of science, as recent cases have shown where programming errors basically invalidated entire studies)

dTal 6y ago
>Categorically demanding complete backward compatibility puts huge limitations on the development of the language Not really. Just introduce an optional version declaration at the top of the file, which guarantees the old behavior. Then feel free to tinker with the design as much as you want. It's a solved problem and it works well. Sure, you still break people's code if they don't put a version declaration in - but now the fix is a single line. The fatal flaw in Python's approach was cleaving apart the Python2 and Python3 worlds, making it impossible to mutually import modules. Python2 and Python3 are practically speaking different languages - different syntax, different semantics, different libraries, and a different userbase. As far as the computer is concerned, they are separate entities, with the feeble "2to3" program being the only thing linking them.
- takeda 6y ago
  Actually I did some small tests, and you could mix python2 and python3 code together through use of Cython. You can use Cython to compile your python 2 code into .so objects and then include them in Python 3. Then you can progressively migrate code file by file to Python 3. I didn't do it on a larger project, so maybe there are some gotchas, but it seems to work as far as I could test it. Regarding the differences in languages Python 2.7 was actually a bridge to migrate to Python 3. That's why all features of 2.7 were backported from 3 (this was also the reason people saying: "why should I migrate to 3, it doesn't offere anything new". It didn't because everything new was backported. Anyway thanks to this it was actually possible to write code that worked on both Python version. I did it several times. It was actually the easiest when you wrote the code for Python 3 and only used features that 2 had. Add all the `__future__` imports and remaining parts filled with the `six` module.

bartread 6y ago

> If anything, this is reason that people should stop using python. It's also the reason I never started in the first place. It wasn't in any way clear which the right option was during the period of schism, and it went on for an awfully long time. With that being said I'm starting to tinker with Python now simply because it has a great ecosystem for NLP and ML. I certainly need the former, although how much of the latter I'll need (possibly none) is unclear. Regardless, it seems to be the de facto standard language for anything that falls under the broad category of data science to the point where for me to pick up a different language would feel very much like swimming upstream.

the__alchemist 6y ago

I'd like to follow this to its logical conclusion: Are you suggesting that it's desirable to make a new language vice improving an old one? (Related, but separate:) Would you have preferred if Python 3 was released under a different name that didn't include "python"?

xapata 6y ago
No, they should have made the breaking changes more slowly, piece by piece, with a couple minor versions depreciation cycle. Python 3 was too many changes simultaneously. But it also coincided with dramatic changes in the size and variety of the programming community. It was hard to anticipate the troubles, of course easy in hindsight.
Wowfunhappy 6y ago
Yes, if you're going to break compatibility to a great enough extent. It would eliminate an immense amount of confusion. See what Perl did with Raku.
donor20 6y ago
You fail to understand that they purposely broke compatibility for no benefit. That is not improving the language - that is being stupid. In python 2 you could specify a unicode literal with u''. So a natural evolutionary option if you had a unicode addiction and wanted python 3 to be unicode native, would be to treat u'' as unicode literals in python 3 as well. This let's the code run under python 2 still, and then you get unicode in 3. And if you are 3 only, just "blah blah" works as well - nice. But they didn't do that. They purposely took u'' out to make it hard to support 2 and 3. That is absolute stupidity. In other words, they BROKE compatibility for no benefit - but just to break it. They did the same thing with byte handling, jumped the io abstraction in - these things all destroyed performance and use cases.