On 14 February 2014 22:01, Peter Otten <__pete...@web.de> wrote: > M.-A. Lemburg wrote: > >> IMO, it was a mistake to have None return a TypeError in >> comparisons, since it makes many typical data operations >> fail, e.g. >> >> Python2: >>>>> l = [1,2,None,4,5,None,6] >>>>> l.sort() >>>>> l >> [None, None, 1, 2, 4, 5, 6] >> >> Python3: >>>>> l = [1,2,None,4,5,None,6] >>>>> l.sort() >> Traceback (most recent call last): >> File "<stdin>", line 1, in <module> >> TypeError: unorderable types: NoneType() < int() > > While it is trivial to fix > >>>> sorted([1,2,None,4,5,None,6], > ... key=lambda x: (x is None, x)) > [1, 2, 4, 5, 6, None, None] > > maybe the key should be given a name like functools.none_first/none_last in > order to offer a standard approach?
Yeah, I was thinking something similar. I posted an RFE if anyone wants to run with the idea for Python 3.5: http://bugs.python.org/issue20630 (it's also the kind of thing that is quite amenable to inclusion in libraries like six and future for Python 2/3 compatible code bases - in Python 2, it can just be a pass through, while in Python 3 it can actually alter the sort operation to allow None values). At a broaded scale, this thread made me realise it may be worth defining a __key__ protocol so custom comparisons are easier to implement correctly: http://bugs.python.org/issue20632 That would need a PEP, but currently, there are lots of things you need to deal with around hashability, comparison with other types, etc when attempting to define a custom ordering. A new __key__ protocol could provide sensible default behaviour for all of those, such that you only needed to define the other methods if you wanted to override the defaults for some reason. (As noted in the issue, this is also amenable to being implemented as a third party module prior to proposing it as a language feature) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ 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
