[peterwwillis]

This is part of the code-as-docs ethos which has really changed how I write everything. I try to make my code as intuitive as possible to obviate comments and documentation that only explain what the code is doing. You could also call it code-as-prose.

This is impeded when languages have popular modules with names that are absolutely unintuitive, like the Python "requests" module. Requests what? Oh, HTTP? Then it should have been called http_requests. And the module that one uses, urllib3, is actually an HTTP library, not a generic URL library (URLs can be any web request, such as ftp, mailto, jdbc, etc).

[heavenlyblue]

>> Requests what? Oh, HTTP? Then it should have been called http_requests. And the module that one uses, urllib3, is actually an HTTP library, not a generic URL library

Python has httplib since 2.7. Also urllib in 3.7 contains all of the URL parsing routines, too.

Naming is a hard problem, so frankly I would prefer if names did not try to mimic their corresponding protocols in the first place at all.

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?

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

[peterwwillis]

> Python has httplib since 2.7. Also urllib in 3.7 contains all of the URL parsing routines, too.

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

[noir_lord]

> I try to make my code as intuitive as possible to obviate comments and documentation that only explain what the code is doing. You could also call it code-as-prose.

I do this, Often I can save typing by liberal use of 'clever' features but I avoid them because if I have to stop to reason them out the poor sod reading my code (Which is often me in 6mths) will as well.

It's one of the things I dislike the most about JS, there are 18 different ways to skin the cat, some of which set the house on fire opposite but only if it's a monday and the cat isn't undefined.

It's what happens when a language accretes instead of gets designed.

I miss Pascal.