A Look Back At Python 3.0 After 10 Years

[grigi]

The reason aiohttp isn't part of standard library, is the same reason that requests isn't part of standard library.
They don't want to be pinned down, as they are improving/changing at a much faster rate than python itself.

Also, there is a reliable packaging system that makes it super easy to include extra dependencies in your project.

[TheBlackCat]

The Deluge BitTorrent client is pretty popular and has not been ported to python 3.

Whether applications support python 3 is less of an issue, it is mostly hidden from users. The question is whether python libraries (i.e. packages) are ported. It is hard to find a major one now that isn't either ported or in the process of being ported. There are really only three major projects that haven't had a compatible release yet, and two of those are ported in master while the last is basically only used internally by mozilla and is in the process of being ported. Further, several major ones have dropped Python 2 support, and many others will do so within the next two years.

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

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

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

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

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

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

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