A Look Back At Python 3.0 After 10 Years

[TheBlackCat]

I don't want to have to write my own async http request library. I just want to quickly be able to do the stuff I want. Just start firing away HTTP requests.
I expect a modern language to be able to perform asynchronous HTTP requests.
Other languages like C# on the .NET platform allows you to perform asynchronous HTTP requests out-of-the-box using HttpClient.
JavaScript lets you do async HTTP using the fetch API.

To be fair, Python predates HTTP, not to mention JavaScript or C#. It only got built-in async programming in 2014, and that is still developing. So it is not surprising that there is still a lot of development in async-related libraries that preclude them being included in the standard library.

[Vistaus]

Which as said you would only consider if you have to deploy to machines without internet, where that particular library probably isn't actually going to be needed...

Exactly. Also, I don't see why one couldn't install it locally if needed on the deployment target. I mean: it's a super small library, not a big, fat app.

[Vistaus]

Again, apps aren't really the issue since end-users don't see the interpreter it is running on. The things that have been ported are the libraries.

Again, where did I say it was an issue? I just posted about apps that haven't been ported yet. It was a conclusion, nothing more, nothing less.

[brrrrttttt]

I don't want to have to write my own async http request library. I just want to quickly be able to do the stuff I want. Just start firing away HTTP requests.
I expect a modern language to be able to perform asynchronous HTTP requests.
Other languages like C# on the .NET platform allows you to perform asynchronous HTTP requests out-of-the-box using HttpClient.
JavaScript lets you do async HTTP using the fetch API.

Which as said you would only consider if you have to deploy to machines without internet, where that particular library probably isn't actually going to be needed...

[uid313]

A third-party dep in an ecosystem designed for trivial deployment with third-party deps isn't really a problem... except when your deployment target doesn't have internet access of course which I've had to deal with a few times. Of course you can also trivially write an async http request library with python 3.5ish+ stdlib anyhow.

I don't want to have to write my own async http request library. I just want to quickly be able to do the stuff I want. Just start firing away HTTP requests.
I expect a modern language to be able to perform asynchronous HTTP requests.
Other languages like C# on the .NET platform allows you to perform asynchronous HTTP requests out-of-the-box using HttpClient.
JavaScript lets you do async HTTP using the fetch API.

[brrrrttttt]

I am sure aiohttp is great, but it's not part of the Python Standard Library. So it introduces an third-party dependency. It's not installed by default.
I expect to be able to perform asynchronous HTTP requests with the standard library of a modern language.

A third-party dep in an ecosystem designed for trivial deployment with third-party deps isn't really a problem... except when your deployment target doesn't have internet access of course which I've had to deal with a few times. Of course you can also trivially write an async http request library with python 3.5ish+ stdlib anyhow.

[TheBlackCat]

BleachBit and Deluge are two apps that haven't been ported yet. Both of them, but esp. Deluge, are not outdated nor niche.

Again, apps aren't really the issue since end-users don't see the interpreter it is running on. The things that have been ported are the libraries.

[schmidtbag]

I am sure aiohttp is great, but it's not part of the Python Standard Library. So it introduces an third-party dependency. It's not installed by default.
I expect to be able to perform asynchronous HTTP requests with the standard library of a modern language.

Python is a bit of an unusual case where most things you need can be found in standard libraries. To my knowledge, you can't say the same about almost any other language, except maybe Java. Restricting yourself to standard libraries could be real crippling. For me personally, I go with libraries that seem to have a large userbase and seems to be frequently updated. Take numpy for example - that's a 3rd party library, but that isn't going to lose maintainers in the foreseeable future.

But like I said, if you really want to use standard libraries but want async, look into using multiprocessing or thread. Those are standard libraries and they allow you to make anything async.

[uid313]

What's wrong with using aiohttp? Also depending on what you're trying to do, you can always try the multiprocessing or thread libraries. Note the latter keeps your application single-threaded, but from what I recall, it makes memory management easier.

I am sure aiohttp is great, but it's not part of the Python Standard Library. So it introduces an third-party dependency. It's not installed by default.
I expect to be able to perform asynchronous HTTP requests with the standard library of a modern language.

[Vistaus]

I think you're right, though I personally haven't used Twisted much. It was way too overkill for my needs, and as a result, needlessly overcomplicated. But, it does seem to serve a lot of purposes that other libraries don't seem to do.
My main interest with Python+HTTP is WebSocket. Twisted supports that too, but not in an elegant way. It's been a while since I've checked, but there was this very basic library that accomplished WebSocket with far less effort and was only a couple hundred KB.


To my knowledge, there is almost nothing worth caring about that hasn't been ported. If a program or library is still on Python 2, it is likely outdated or too niche.

BleachBit and Deluge are two apps that haven't been ported yet. Both of them, but esp. Deluge, are not outdated nor niche.