> urllib? Well, yeah - simply because someone wanted to provide a simple HTTP interface. By the way - urllib also provides FTP/local file access routines. So it does mean "a library to access URLs".

You're missing my point. These are just random examples of bad naming convention. Yes, Python has some core modules which sort of relate to their name... but everyone uses "requests" and "urllib3", not "httplib" and "urllib" (and urllib3 has no FTP support). And yes, you can name a simple http module anything you want, but if it's unintuitive, it's counter-productive to the humans that have to work with it.

> It gets even worse when you would like to support HTTP and async HTTP; then HTTP/2, HTTPS, HTTP server, etc... Which one of these libraries are supposed to be actually called "http"? What if there's two libraries with the same functionality?

The common solution is to create modules that inherit from parents, to extend base modules for more specific functionality. The names then become hierarchical - io, io::net, io::net::http, io:net::http::2, io::net::http::secure, io::net::http::server, io::net::http::client, and so on.

For whatever reason, Python doesn't support this, and instead creates new unique packages rather than extending pre-existing ones. It's rather annoying for multiple reasons, but specifically to my original point, it isn't code-as-docs.