5 ms·

Upgrading the OS is also annoying, so why not just stay in one place for next 5, 10, 50? years. If you don't upgrade your machine it probably will continue to w

by takeda 7y ago

Upgrading the OS is also annoying, so why not just stay in one place for next 5, 10, 50? years. If you don't upgrade your machine it probably will continue to work, python 2 won't disappear. I wish PSF would pull the plug from python 2 much sooner so we wouldn't have to deal with whiners for 10 f...ing years. The problem with python 3 wasn't the incompatibility, the problem was keeping python 2 alive for so long. Other languages usually gave only 1 year and everyone moved, because they didn't want to stay behind.

CJefferson 7y ago
Which other languages? My C89 code, C++98 code and Fortran 77 code all still compile on a modern Ubuntu, and none of these are expected to break any time soon. The compilers just support multiple versions.
- joshuamorton 7y ago
  I'd strongly suggest watching "What is C++" [0] from this year's cppcon. There's a lot of good content, but the relevant bit is that c especially (remember, c++98 is younger than python2!) values backwards compatibility very highly. This is sometimes useful, but it has costs. Performance costs, safety costs, and especially ergonomic/complexity costs for future development (the kitchen-sink-ness of modern cpp). People aren't wrong to make different tradeoffs than you. Especially given that strict backwards compatibility is impossible (especially in a language like c/++, people will rely on things that aren't intentionally public, because they can introspect your bytes). Compiler changes break code all the time, it's just almost always semantic and not syntactic. I find this amusing, since the syntactic changes are usually easier to detect and fix. And python2 still works, it just won't get new features. [0]: https://youtu.be/LJh5QCV4wDg https://youtu.be/LJh5QCV4wDg
  - hermitdev 7y ago
    > And python2 still works, it just won't get new features. Probably more importantly, it wont get security fixes. Yeah, Python 2 will still work. Ita not like there's a kill switch or anything. It just wont receive any official or supported updates. Effectively, Py2 will be abandonware.
- __david__ 7y ago
  Those languages also don’t have massive runtime libraries with thousands of potential bugs that may even be security holes. They are not comparable in the slightest.
- gpderetta 7y ago
  I have been extremely critical of the P2 to P3 drama, but to be totally fair, things haven't been as smooth as we like to remember in C++ land. While the c++11 standard (and successors) are highly compatible with c++98, most compilers at the turn of the millennium had questionable conformance and each compiler upgrade to a more recent and strict version was a lot of pain (I still remember the pain when GCC started enforcing two phase lookup).
  - CJefferson 7y ago
    I agree things could be better in c++, but never was never anything like python 3, redefining / , or removing printf. Also, usually once you fixed your code, it still worked in older compilers (although not always).
    - gpderetta 7y ago
      Yes also often the compiler would tell you exactly what to do (90% of the time it was a missing typename).
    - hermitdev 7y ago
      While I generally agree with your comment, Python generally gives easily accessible migration paths. Regarding your division example, you could import from __future__ integer_division (maybe it was another name?) Since I think Python 2.5 before it became the default in, I think, 2.7. I wish the wallrus operator was available as a future import, bit it's not. Also, Python never had printf. It had a print statement; print became a function in Python 3. Yes, its a syntax change, but its for the better. Having print as a first class statement expands its utility and versatility.
      - CJefferson 7y ago
        Removing printf was an example of a change C++ could make of similar effect (they could argue you should be using cout, so you don't need it). Sorry it was unclear
    - lenzm 7y ago
- takeda 7y ago
  Ruby broke applications and it wasn't even major version release I think it was 1.8 to 1.9. Tcl 8.3 to 8.4 when they added unicode support as well. I believe PHP did similar thing.
  - dragonwriter 7y ago
    > Ruby broke applications and it wasn't even major version release I think it was 1.8 to 1.9. It was a major version release; Ruby, through 1.8, used an version numbering scheme similar to the old Linux version numbering scheme; odd second digits were development major versions, even second digits were stable major versions. 1.9 was a slight break because it was a major release but, IIRC, seen as stable.
mikepurvis 7y ago
Ugh, another one of these threads. Python 3 came out in December 2008. But for a lot of packages, it wasn't realistic to migrate until it was possible to support both Pythons from the same codebase. And that wasn't realistic until 2.7/3.3, which was 2012. At that point the rising tide started and packages with no dependencies began doing dual support. But it was many years before there was enough coverage that application level packages like django could consider migrating. So yes, the cutoff could have been somewhat sooner, but if the PSF had attempted to force a transition in 2009, it would have been a death knell for Python. Not even numpy was available for Python 3 until 2011!
- hermitdev 7y ago
  Yeah, I started using Python 3 immediately. By biggest pain point was probably print going from a statement to a function, which while I agree it was the right move, I still have muscle memory that wants to use the statement. There are a few other pain points, like Unicode encoding, csv line endings. But, what prevented me from moving earlier was lack of 3rd party support. Things like DB and MQ access...
- takeda 7y ago
  Python 3.3 was 8 years ago, packages started really migrating in 2015 when PSF stopped adding new features to Python 2.7.
- sitkack 7y ago
  The PSF actively discouraged folks from writing packages that were compatible with both. They wanted a hard schism and even tacit support for 2 was to reject the wishes of the church.
  - mikepurvis 7y ago
    The original proposal from GvR for dual support in libraries was to release separate source, where the Py3 version would be the generated output of running source transformation tools like 2to3 against the Py2 source: https://www.python.org/dev/peps/pep-3000/#compatibility-and-transition https://www.python.org/dev/peps/pep-3000/#compatibility-and-... Not hard to see why this didn't get a lot of traction.

by takeda 7y ago

CJefferson 7y ago

Which other languages? My C89 code, C++98 code and Fortran 77 code all still compile on a modern Ubuntu, and none of these are expected to break any time soon. The compilers just support multiple versions.

joshuamorton 7y ago
I'd strongly suggest watching "What is C++" [0] from this year's cppcon. There's a lot of good content, but the relevant bit is that c especially (remember, c++98 is younger than python2!) values backwards compatibility very highly. This is sometimes useful, but it has costs. Performance costs, safety costs, and especially ergonomic/complexity costs for future development (the kitchen-sink-ness of modern cpp). People aren't wrong to make different tradeoffs than you. Especially given that strict backwards compatibility is impossible (especially in a language like c/++, people will rely on things that aren't intentionally public, because they can introspect your bytes). Compiler changes break code all the time, it's just almost always semantic and not syntactic. I find this amusing, since the syntactic changes are usually easier to detect and fix. And python2 still works, it just won't get new features. [0]: https://youtu.be/LJh5QCV4wDg https://youtu.be/LJh5QCV4wDg
- hermitdev 7y ago
  > And python2 still works, it just won't get new features. Probably more importantly, it wont get security fixes. Yeah, Python 2 will still work. Ita not like there's a kill switch or anything. It just wont receive any official or supported updates. Effectively, Py2 will be abandonware.
__david__ 7y ago
Those languages also don’t have massive runtime libraries with thousands of potential bugs that may even be security holes. They are not comparable in the slightest.
gpderetta 7y ago
I have been extremely critical of the P2 to P3 drama, but to be totally fair, things haven't been as smooth as we like to remember in C++ land. While the c++11 standard (and successors) are highly compatible with c++98, most compilers at the turn of the millennium had questionable conformance and each compiler upgrade to a more recent and strict version was a lot of pain (I still remember the pain when GCC started enforcing two phase lookup).
- CJefferson 7y ago
  I agree things could be better in c++, but never was never anything like python 3, redefining / , or removing printf. Also, usually once you fixed your code, it still worked in older compilers (although not always).
  - gpderetta 7y ago
    Yes also often the compiler would tell you exactly what to do (90% of the time it was a missing typename).
  - hermitdev 7y ago
    While I generally agree with your comment, Python generally gives easily accessible migration paths. Regarding your division example, you could import from __future__ integer_division (maybe it was another name?) Since I think Python 2.5 before it became the default in, I think, 2.7. I wish the wallrus operator was available as a future import, bit it's not. Also, Python never had printf. It had a print statement; print became a function in Python 3. Yes, its a syntax change, but its for the better. Having print as a first class statement expands its utility and versatility.
    - CJefferson 7y ago
      Removing printf was an example of a change C++ could make of similar effect (they could argue you should be using cout, so you don't need it). Sorry it was unclear
  - lenzm 7y ago
takeda 7y ago
Ruby broke applications and it wasn't even major version release I think it was 1.8 to 1.9. Tcl 8.3 to 8.4 when they added unicode support as well. I believe PHP did similar thing.
- dragonwriter 7y ago
  > Ruby broke applications and it wasn't even major version release I think it was 1.8 to 1.9. It was a major version release; Ruby, through 1.8, used an version numbering scheme similar to the old Linux version numbering scheme; odd second digits were development major versions, even second digits were stable major versions. 1.9 was a slight break because it was a major release but, IIRC, seen as stable.

mikepurvis 7y ago

Ugh, another one of these threads. Python 3 came out in December 2008. But for a lot of packages, it wasn't realistic to migrate until it was possible to support both Pythons from the same codebase. And that wasn't realistic until 2.7/3.3, which was 2012. At that point the rising tide started and packages with no dependencies began doing dual support. But it was many years before there was enough coverage that application level packages like django could consider migrating. So yes, the cutoff could have been somewhat sooner, but if the PSF had attempted to force a transition in 2009, it would have been a death knell for Python. Not even numpy was available for Python 3 until 2011!

hermitdev 7y ago
Yeah, I started using Python 3 immediately. By biggest pain point was probably print going from a statement to a function, which while I agree it was the right move, I still have muscle memory that wants to use the statement. There are a few other pain points, like Unicode encoding, csv line endings. But, what prevented me from moving earlier was lack of 3rd party support. Things like DB and MQ access...
takeda 7y ago
Python 3.3 was 8 years ago, packages started really migrating in 2015 when PSF stopped adding new features to Python 2.7.
sitkack 7y ago
The PSF actively discouraged folks from writing packages that were compatible with both. They wanted a hard schism and even tacit support for 2 was to reject the wishes of the church.
- mikepurvis 7y ago
  The original proposal from GvR for dual support in libraries was to release separate source, where the Py3 version would be the generated output of running source transformation tools like 2to3 against the Py2 source: https://www.python.org/dev/peps/pep-3000/#compatibility-and-transition https://www.python.org/dev/peps/pep-3000/#compatibility-and-... Not hard to see why this didn't get a lot of traction.