Hacker News new | comments | show | ask | jobs | submit login
Show HN: Asynchronous HTTP/2 client for Python 2.7 (github.com)
94 points by vsmhn 7 months ago | hide | past | web | favorite | 57 comments



Qt has an event loop and async http library. I've used it from PyQt with great success.


Does it support HTTP/2?



This other th2c library is MIT licensed, that might be appreciated by some people.


Why Python 2 and not Python 3?

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.


Hey, I posted an issue on the repo for a Python 3 port here: https://github.com/vladmunteanu/th2c/issues/27. I think you should give the same explanation there as you did here and close it outright as what you said makes sense. There is still a lot of Python 2.x code being written out there with companies looking for quick ways to upgrade their stack. While I wish it weren't so, your point makes a lot of sense.


How does that compare to aiohttp? What are the benefits?


I'm not sure I understand the question, are you interested in comparing tornado and aiohttp?


aio isn't available for py2. The benefit is that this is available for py2.


There is https://github.com/vstinner/trollius for vanilla Python2.


trollius is no longer maintained


It's still a reasonable starting place for anyone wanting asyncio on vanilla Python2. Outside of vanilla Python2, Tauthon also has some tracking issues for the language extensions and libraries needed for a backport of asyncio to Tauthon.[0]

[0]: https://github.com/naftaliharris/tauthon/issues/10


I’m of the opinion that one should only maintain python2 projects not actively develop and expand them. If your project needed http2 then it should be ported to python3.

Edit: would using python3 in a container make sense where the distribution only ships legacy python?


The current version of Redhat - RHEL 7 - which most banks, large enterprises etc. are using comes with a system python version of 2.7.5 and you need to jump through hoops to install Python 3.x ( e.g. https://stackoverflow.com/questions/8087184/problems-install... ), which may not even be possible if you're in an environment where security is tightly controlled.

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


Developers relying on OS scripting runtimes for their applications are misusing the OS; and environments that only allow the use of OS scripting runtimes are fundamentally misunderstanding their job.

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.



>you need to jump through hoops to install Python 3.x

What? You can install Python 3.6 from EPEL[1], takes 5 seconds.

[1] https://fedoraproject.org/wiki/EPEL


Then you have to use scl, which kind of sucks. Better to just install the fedora packages. Or compile it yourself (but you should really package it if you're deploying it on a lot of servers)


Meh, RHEL customers can look after themselves and maintain a python2 fork. Unless they’re paying you it makes sense to target the most recent version of the language.


I’m not an enterprise developer but does RHEL 7 support docker? Run python3 in a container. Isn’t that the point of containers?


you mean bringing code which has not been cleared as secure & authorized by corporation's legal experts? BigCorp makes all those easy things hard (usually after lessons learnt).


Even if you run official builds by the python foundation from the library on docker hub? That seems like a business opportunity: certify software for RHEL by all the government bodies and pay RH for sign off and then be the only vendor to be sanctioned to run “third party but vetted” python3.


If a group has a security policy that makes it hard for them to install Python 3, of course there's no way in hell they're installing Docker.


fair enough i didn't know these things; learned something new today.


What if a company has a large codebase that's in Python 2 and wants http2? Will those suggesting porting help them bear the costs and manhours it takes?

(Google, for one, still uses 2. As does Dropbox. And both companies had Guido Van Rossum working for them at some point).


> What if a company has a large codebase that's in Python 2 and wants http2? Will those suggesting porting help them bear the costs and manhours it takes?

This is why banks still use COBOL and Fortran.


More power to them!


Companies are going to have to port at some point.


Google has Grumpy. Because writing a compiler is easier than porting. https://github.com/google/grumpy


Not sure about that. Some companies may have codebases as complicated as the python codebase itself. For them it may make more sense to maintain python2 than to upgrade. Granted, there will be very few such companies.


Python 2 is popular enough that someone will keep up support for decades to come. Just making sure it supports new OS releases, and fixing the occasional bug, will not be a significant overhead.


Unjustifiable assertion.

  - 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)
  ...


GVR has already said that Python 4 (if it's even ever called that) will not have the same kind of breaking changes 3 did.


And 3 had different changes than 2 (https://docs.python.org/3/whatsnew/2.0.html) though it is interesting that Unicode support was a big feature in both, and that many people still find Python3’s Unicode support problematic (e.g., http://lucumr.pocoo.org/2014/5/12/everything-about-unicode/)

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.


The whole point of my comment is that there won't be a "next big change", just lots of smaller ones.


All aforementioned large companies have a diverse tech stack rather than a single stack, let alone programming language versions. Having Python BDFL working for them doesn't necessarily mean they will follow Python community consensus. Neither was Guido tasked to help them upgrade their python stack to 3.x AFAIK.

Python core team will eventually cease support 2.x support at some point[1], 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?

[1]: https://pythonclock.org/


> 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?


> Once again, the point is that software will continue working beyond that deprecation event.

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.



Any specific reason to develop this for Python 2 rather than Python 3?


There's still a lot of existing and new Python 2 code being written. Idealistically we would all be on Python 3, but software is a messy land.


It's been ten years, so it's gone beyond "idealistically".


It hasn't been anything close to that long since major libraries mostly worked on 3, though. You can't just declare the old version of a major software ecosystem dead because you updated one part of it. We've seen it with operating systems, we've seen it with browsers, and we also see it with programming languages and all the libraries and tools that make them useful.


Still not distributed by default on Mac or Ubuntu long term release, unlike 2.


The current Ubuntu long-term support release is Xenial, which comes with only Python 3 installed. If you're talking about Trusty, its support is ending fairly soon.

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.


Woops, my LTS is obviously out of date. Thanks.


It has not been ten years, as only Python 3.6 and later is considered finalised.


The end of life is in 2020 but it doesn’t say when.

Is this still the latest?

http://legacy.python.org/dev/peps/pep-0373/



Its name made me think of THC.

I'll ask the obvious question: why not Python 3?


Well, Python 3 already has a similar library that deals with this stuff, such as https://github.com/decentfox/aioh2.

Also, this is mostly intended for Tornado backends, offering compatibility with Tornado's request / response objects.


I see. May I suggest linking to that in the README? And if you aren't part of the Python 2 forever camp, suggest how one might migrate from using your library to using python 3 with the other library in the future? And if the APIs aren't similar it might be a good idea to make them similar.


I understand your point, and I'll try to update the README with that information. However, this client tries to follow Tornado's ways, whereas aioh2 works on Python's asyncio.

It's still WIP, so feedback like yours helps a lot, thanks!


Are people really still so closely wedded to Python 2 that they find it easier to reimplement all the features they need from Python 3 in the former, instead of switching to the latter?


yes.

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.


Just think of any large code base and it should be obvious.

What's simpler, rewriting a massive project, or maintaining a library? For example, OP did the latter himself.


Yes.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: