3 ms·

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 suppo

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.
  - sitkack 7y ago
    No they don’t. Step functions usually signify the change in evolutionary epochs. Meaning any time the change is too great, it literally means starting over. Python barely survived 2to3, it should serve as a warning to every other system that thinks it can do a stop the world upgrade.

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.
- sitkack 7y ago
  No they don’t. Step functions usually signify the change in evolutionary epochs. Meaning any time the change is too great, it literally means starting over. Python barely survived 2to3, it should serve as a warning to every other system that thinks it can do a stop the world upgrade.