7 ms·

Ya, there's no way this is the "final" release. Maybe by the core Python team, but it will be forked to fix bugs. Ten years from now there will still be Pytho

Ya, there's no way this is the "final" release. Maybe by the core Python team, but it will be forked to fix bugs. Ten years from now there will still be Python 2 code running critical infrastructure at various companies, and the most responsible path to address discovered issues in the runtime will not be "rewrite the application to work in Python 3!" but "upgrade the interpreter to this community-vetted fork of 2.7.18". Mumble mumble something about conflating languages with implementations.

tom_mellior 7y ago
> Mumble mumble something about conflating languages with implementations. So your claim is that "Python 2" is a language spec, not an implementation? And that there will be future releases of this language spec in the future? I doubt it. I agree it's likely that there will be people wasting their time maintaining an interpreter fork, but that will not be Python-the-language (a trademarked term BTW), it will be a fork of the implementation.
- colanderman 7y ago
  No, my claim is that, while ceasing development of the language Python 2 is wholly sensible, ceasing development of the implementation Python 2 (CPython specifically) is not (due the almost certain existence of latent bugs). My "mumble" at the end was meant exactly in reference to that. I suppose one could argue that, the CPython implementation is the language specification. (And I seem to recall hearing that notion somewhere years ago.) In which case, it would not be possible to freeze development of the language without freezing the implementation as well. There are various reasons I wholeheartedly disagree with such a characterization, but I guess there's some self-consistency there at least.
  - nxpnsv 7y ago
    This is clear, but does the cpython team want to maintain Python2? If not, either it’s time to use an alternative or move on....
  - tom_mellior 7y ago
    > ceasing development of the language Python 2 is wholly sensible, ceasing development of the implementation Python 2 (CPython specifically) is not Development of CPython 2 has ended, bugs and all. It's past its end of life, this is well known and has been known for a long time. Any remaining bugs are the problem of the users, not the responsibility of the former developers. Sure people will fork it and do stuff with those forks, but those will no longer be new versions of CPython, they will be new versions of some-fork-of-CPython.
- j88439h84 7y ago
  > So your claim is that "Python 2" is a language spec, not an implementation? And that there will be future releases of this language spec in the future? PyPy maintains a Python 2 implementation and will continue to do so.
- carapace 7y ago
  > "Python 2" is a language spec Cython, IronPython, Brython, Stackless Python, Nuitka, etc.
anon73044 7y ago
More likely by then the push to "RIIR"™ will be so overwhelming that most people won't be able to help themselves.
- anon73044 7y ago
  Glad to have struck a nerve with the Rust evangelists.
takeda 7y ago
What's use of Python 2 if you can't use libraries[1]? It will only get more difficult to maintain your app. [1] https://python3statement.org/ https://python3statement.org/ - note many libraries weren't even waiting until 2020. It is a lot of work to maintain code with python 2 cruft. Not all packages are listed there, for example Django is Python 3 only, starting from 2.0 (currently at 3.0)
- philwelch 7y ago
  The problem isn't that Python 2 is bad. Python 2 is a fantastic language. The problem is that the maintainers of Python decided to break backwards compatibility and force library developers to support what are essentially two different programming languages.
  - kstrauser 7y ago
    I don’t think there was any clear path around that, though. The single biggest change was that Python 2 pretended that text and binary data were the same datatype, where Python 3 correctly makes you distinguish between the two. There’s not really a great way to roll out that major change without breaking tons of stuff along the way. And, well, if you’re already making a backward-incompatible version, here’s this checklist of other breaking changes you might as well bring along for the ride.
    - someguydave 7y ago
      > correctly Sometimes it’s better to be correct and also yield to the common good.
    - afiori 7y ago
      some would say that the distinction was in the wrong places, like assuming that the command line arguments or file paths were utf8
      - int_19h 7y ago
        Python 3 does not make such assumptions; it uses the appropriate locale encoding. (IIRC it used to do that in 3.0, but they backtracked very quickly - and 3.0 was effectively treated as a beta by the community at large, anyway.)

tom_mellior 7y ago

> Mumble mumble something about conflating languages with implementations. So your claim is that "Python 2" is a language spec, not an implementation? And that there will be future releases of this language spec in the future? I doubt it. I agree it's likely that there will be people wasting their time maintaining an interpreter fork, but that will not be Python-the-language (a trademarked term BTW), it will be a fork of the implementation.

colanderman 7y ago
No, my claim is that, while ceasing development of the language Python 2 is wholly sensible, ceasing development of the implementation Python 2 (CPython specifically) is not (due the almost certain existence of latent bugs). My "mumble" at the end was meant exactly in reference to that. I suppose one could argue that, the CPython implementation is the language specification. (And I seem to recall hearing that notion somewhere years ago.) In which case, it would not be possible to freeze development of the language without freezing the implementation as well. There are various reasons I wholeheartedly disagree with such a characterization, but I guess there's some self-consistency there at least.
- nxpnsv 7y ago
  This is clear, but does the cpython team want to maintain Python2? If not, either it’s time to use an alternative or move on....
- tom_mellior 7y ago
  > ceasing development of the language Python 2 is wholly sensible, ceasing development of the implementation Python 2 (CPython specifically) is not Development of CPython 2 has ended, bugs and all. It's past its end of life, this is well known and has been known for a long time. Any remaining bugs are the problem of the users, not the responsibility of the former developers. Sure people will fork it and do stuff with those forks, but those will no longer be new versions of CPython, they will be new versions of some-fork-of-CPython.
j88439h84 7y ago
> So your claim is that "Python 2" is a language spec, not an implementation? And that there will be future releases of this language spec in the future? PyPy maintains a Python 2 implementation and will continue to do so.
carapace 7y ago
> "Python 2" is a language spec Cython, IronPython, Brython, Stackless Python, Nuitka, etc.

anon73044 7y ago

More likely by then the push to "RIIR"™ will be so overwhelming that most people won't be able to help themselves.

anon73044 7y ago
Glad to have struck a nerve with the Rust evangelists.

takeda 7y ago

What's use of Python 2 if you can't use libraries[1]? It will only get more difficult to maintain your app. [1] https://python3statement.org/ https://python3statement.org/ - note many libraries weren't even waiting until 2020. It is a lot of work to maintain code with python 2 cruft. Not all packages are listed there, for example Django is Python 3 only, starting from 2.0 (currently at 3.0)

philwelch 7y ago
The problem isn't that Python 2 is bad. Python 2 is a fantastic language. The problem is that the maintainers of Python decided to break backwards compatibility and force library developers to support what are essentially two different programming languages.
- kstrauser 7y ago
  I don’t think there was any clear path around that, though. The single biggest change was that Python 2 pretended that text and binary data were the same datatype, where Python 3 correctly makes you distinguish between the two. There’s not really a great way to roll out that major change without breaking tons of stuff along the way. And, well, if you’re already making a backward-incompatible version, here’s this checklist of other breaking changes you might as well bring along for the ride.
  - someguydave 7y ago
    > correctly Sometimes it’s better to be correct and also yield to the common good.
  - afiori 7y ago
    some would say that the distinction was in the wrong places, like assuming that the command line arguments or file paths were utf8
    - int_19h 7y ago
      Python 3 does not make such assumptions; it uses the appropriate locale encoding. (IIRC it used to do that in 3.0, but they backtracked very quickly - and 3.0 was effectively treated as a beta by the community at large, anyway.)