Short answer is: because Python 3 already benefits from a better, more complete client: aioh2 (https://github.com/decentfox/aioh2) that works with Python's asyncio.
th2c is mostly intended for Tornado backends, trying to keep a similar interface and compatibility with Request / Response objects.
It was initially developed in order to be able to communicate with APNS from a python 2.7 environment.
Edit: would using python3 in a container make sense where the distribution only ships legacy python?
There is the possibility of Python 3.x being default in RHEL 8 ( https://fedoraproject.org/wiki/Changes/Python_3_as_Default ) but right now RHEL 8 isn't released and there's no date for it being released. And even once it is released, it will be more years before big enterprises really start switching
TLDR ignore python 2.7 and alienate RHEL customers
OS scripting runtimes are there for the OS to use, in its system software and services. Such runtimes are not there for anyone else to use. They’re implementation details of the OS.
This is the reason that certain platform-bytecode libraries get packaged into OS packages, while most don’t. Those packages are also there strictly for the OS itself to use, with versioning allowing other OS packages to rely on them. If you’re not writing OS software (e.g. something that runs under init(8), speaks D-Bus, is part of minimal installs, etc.) then you shouldn’t be relying on those packages.
Consider the fact that a lot of “application software” OS packages—packages shipped by the distro!—actually vendor their own runtime and libraries. They do this because they have separate needs from the super-stable-but-minimal runtime provided by the OS.
If not even the distros themselves think it’s worthwhile to rely on the OS runtime for everything, you shouldn’t either.
Unless your software’s relationship with a daemon or library is “I expect that it was already here when I got here, because that exact ABI version of it is part of the definition of the platform we target”—just vendor the dang deps.
Yes, they become your responsibility to audit. The distro was never going to do that job for any software not required to run itself anyway.
What? You can install Python 3.6 from EPEL, takes 5 seconds.
(Google, for one, still uses 2. As does Dropbox. And both companies had Guido Van Rossum working for them at some point).
This is why banks still use COBOL and Fortran.
- they could continue to maintain python2
- they could move to a non-python platform
- they could go out of business
- they could hold out for Python4 (Python3 was only 8 years after Python2)
But if an individual or organization does not find the python 3 updates and ecosystem a compelling upgrade over 2, “don’t update until the next big change” is definitely one option.
Python core team will eventually cease support 2.x support at some point, so the ones who uses 2.x will be on their own. Will the cost of self-patching python 2.x lower than rewrite the software application you developed on 2.x? Well, that's on them to decide. After 2.x being officially deprecated, what's the point of having a Async HTTP/2 client working (mostly back-porting features that's already on 3k) on 2.x?
Once again, the point is that software will continue working beyond that deprecation event.
As you said, the cost/benefit analysis of a rewrite isn't always in favor of a rewrite at that point in time. So what must follow is that there will be Python 2 software out in the wild for some time regardless of support. What other possibility is there?
Yes, python 2.x code will work - but in the event major CVEs for a piece of software stack that's deprecated, you are left to no choice but to fix on your own. Those sometime are by no means no small feat! And mind you this is an ongoing battle to patch up security holes.
On Xenial, you have to separately install an optional package for Python 2. When you try to run /usr/bin/python on a fresh Xenial install, it'll tell you that you need to install a package such as python-minimal==2.7.11, whereas /usr/bin/python3 is already there.
Is this still the latest?
I'll ask the obvious question: why not Python 3?
Also, this is mostly intended for Tornado backends, offering compatibility with Tornado's request / response objects.
It's still WIP, so feedback like yours helps a lot, thanks!
I had a coworker who was against moving to python3(and kept on writing python2 code for a while) because you need to use brackets with python3 print statement.
What's simpler, rewriting a massive project, or maintaining a library? For example, OP did the latter himself.