Hector Martin

Besides, defaulting to a string operation is consistent with join() and split(). Better than sorting with heterogeneous types, which isn't even well-defined.

It's inconsistent with the comparison operators... which is what sort is all about. Comparing things. And would work as intended when the types are homogeneous, as is the case here. That's the only reasonable way to implement this.

Default sort functions are useless outside of toy examples anyway. If you're not passing a comparator, your data is trivial in the first place.

95% of the time I call sort in Python I don't pass a comparator. 75% of the time I don't even pass a key function. Why would sorting "trivial" data not be expected to work as intended?

Clearly we work in different fields. Of course it SHOULD work as intended, but in Python and JS both I'm sorting objects/dicts most of the time.

75% of the time I'm sorting either a basic data type or a bunch of tuples in lexicographical order (i.e. (key, value)). 20% of the time I'm sorting dicts/objects and just pass a key function (which JS doesn't even support). Only 5% of the time do I need a custom compare.

Fair enough, lexicographical sorting for tuples was a case I'd forgotten about because I don't write enough Python nowadays. (Also, Python's key function is a special case of custom compare, so I wouldn't separate those.)

The point is that a key function only extracts the key and does not change comparison behavior. Yes you can implement it with a custom compare, but it's useful on its own (but wouldn't be very useful in JS due to the dumb default string sort).