> There’s no need for adding say, len, to every object that needs a len function.

fwiw, Ruby does the same thing, but using the Enumerable mixin rather than a free floating function.

> I’d argue that is consistent.

I don’t understand this argument. It’s convenient and more efficient to write, yes. But how is it more consistent to have two different calling conventions?

The claim that there’s one way to do something irks me as well. There’s one way to find the length of something, but that introduces two ways of querying an object. It’s a good guiding principle, but when people use it to make stronger claims, it ends up superficial.

By which I mean that you can consistently use `len` etc on any iterable and they will always behave in the same way. You learn them on day one and they work consistently in every place you see them forever.

> There’s no need for adding say, len, to every object that needs a len function. I’d argue that is consistent.

Python's len works by calling the __len__ method, which must be added to every class that needs a len function.

Since you're already defining a method with a standard name on every class that needs it, Ruby just has you call that method directly as opposed to the absurdity of intentionally obfuscating the method name with underscores so that people use a global helper function instead.

Even C++, with all its warts and its 1980s design got this right in the std lib with the size method.

Honestly, I find some of these defenses of Python quite humorous.

It's almost like they have become memes in themselves. "There is only one way to do it" -> except for those cases where there is a multitude, including the base choice of major release of interpreter, package manager, and so on. Python is very usable but it definitely isn't perfect and the only way you get to improve on stuff is to recognize its shortcomings.

I'd agree that __len__ is a fairly trivial example, but it is used for truthiness in Python too. It seems like a reasonable choice to mark these blessed methods that the language is using deeply as part of the runtime in a special way but I'll happily concede that it could have been X.len() instead.

`sorted`, `list`, `set`, are more interesting cases where they all work with the underlying __iter__ protocol. You don't also want to add X.sorted(), X.as_list(), X.as_set() etc too. Again, you could have X.as_iterable() to implement these, or you could mixin sorted, which will call the __iter__ function. But honestly, it's really neither here nor there.

For the full avoidance of doubt - I'm not arguing for these other "memes" and, in particular, "There is only one way to do it" has never made that much sense to me.

I am arguing that Pythons `sorted` api is reasonable, consistent and not worth worrying about.

Language design is a hard problem. You have to make so many compromises to get it to the point where it works for a large variety of use cases that the degree of ugliness is almost directly proportional to the breadth of application and adoption. The only languages that manage to stay clean are the ones that nobody uses.

I don't think that's avoidable. Mistakes made early on have a habit of compounding over time and calcification makes it harder and harder to deal with them decisively and in a non-breaking way. Python made a couple of bad decisions but on the whole the language came out relatively unscathed, most of the original design constraints are still satisfied. As opposed to say PHP or Java which ended up very far removed from where they started out.

Case in point: Python's GIL must have seemed like a good idea at the time, a quick fix for an urgent problem. And now that quick fix is the albatross that we can't seem to get rid of.

On that we very much agree.

I think it's definitely worth considering what could / can be done better, but people often argue deeply about things that aren't really a massive deal. You've pointed out examples that are much more interesting than "should __len__() have been called len()".

Certainly makes one appreciate Guido's stewardship in keeping the language fairly clean but applicable to large number of use cases for so long!

Yes, I think he did an amazing job. Being the maintainer of a popular open source project is the most thankless job and if the project is a language or an operating system doubly so. Every Tom, Dick & Harriet that has ever opened a CS book will have an opinion and dealing with all that over the years in a courteous way really adds up.