[Tim] >> Guido wanted to drop all the "arbitrary but consistent" mixed-type >> comparison crud for Python 3.
[Greg Ewing] > Nobody is asking for a return to the arbitrary-but- > [in]consistent mess of Python 2, only to bring > back *one* special case, i.e. None comparing less > than everything else. Of course. My point was that dropping None comparisons wasn't specifically aimed at None comparisons. > I think there is a reasonable argument to be made > in favour of that. There may have been 6 years ago, but Python 3 isn't a thought experiment anymore. It was first released over 5 years ago, and has its own compatibility (with Python 3, not Python 2) constraints now. > Like it or not, None does have > a special place in Python as the one obvious way > to represent a null or missing value, and often > one wants to sort a collection of objects having > keys that can take on null values. Perhaps that's often true of your code, but it's never been true of mine. > Refusing to make that easy seems like allowing purity to beat > practicality. Since I've never had a need for it, I can't say for sure whether or not it's easy - but the .sort() interface is rich enough that I almost always find even truly complex key transformations "easy enough". Perhaps a real, concrete use case would help. I have a hard time imagining why I'd _want_ to sort a list of objects with "null or missing" keys, instead of filtering such garbage out of the list first and sorting what remains. But even with a compelling use case, I'd still think it's years too late to change this in Python 3. _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
