On 17.02.2014 12:49, Gustavo Carneiro wrote: > On 17 February 2014 11:43, M.-A. Lemburg <m...@egenix.com> wrote: > >> On 17.02.2014 12:23, Gustavo Carneiro wrote: >>> On 17 February 2014 11:14, M.-A. Lemburg <m...@egenix.com> wrote: >>> >>>> On 15.02.2014 07:03, Stephen J. Turnbull wrote: >>>>> M.-A. Lemburg writes: >>>>> >>>>> > IMO, it was a mistake to have None return a TypeError in >>>>> > comparisons, since it makes many typical data operations >>>>> > fail, e.g. >>>>> >>>>> I don't understand this statement. The theory is that they *should* >>>>> fail. >>>>> >>>>> The example of sort is a good one. Sometimes you want missing values >>>>> to be collected at the beginning of a list, sometimes at the end. >>>>> Sometimes you want them treated as top elements, sometimes as bottom. >>>>> And sometimes it is a real error for missing values to be present. >>>>> Not to mention that sometimes the programmer simply hasn't thought >>>>> about the appropriate policy. I don't think Python should silently >>>>> impose a policy in that case, especially given that the programmer may >>>>> have experience with any of the above treatments in other contexts. >>>> >>>> None is special in Python and has always (and intentionally) sorted >>>> before any other object. In data processing and elsewhere in Python >>>> programming, it's used to signal: no value available. >>>> >>>> Python 3 breaks this notion by always raising an exception when >>>> using None in an ordered comparison, making it pretty much useless >>>> for the above purpose. >>>> >>>> Yes, there are ways around this, but none of them are intuitive. >>>> >>>> Here's a particularly nasty case: >>>> >>>>>>> l = [(1, None), (2, None)] >>>>>>> l.sort() >>>>>>> l >>>> [(1, None), (2, None)] >>>> >>>>>>> l = [(1, None), (2, None), (3, 4)] >>>>>>> l.sort() >>>>>>> l >>>> [(1, None), (2, None), (3, 4)] >>>> >>>>>>> l = [(1, None), (2, None), (3, 4), (2, 3)] >>>>>>> l.sort() >>>> Traceback (most recent call last): >>>> File "<stdin>", line 1, in <module> >>>> TypeError: unorderable types: int() < NoneType() >>>> >>>> >>> Maybe Python 3 should have a couple of None-like objects that compare the >>> way you want: AlwaysComparesLess and AlwaysComparesGreater, but with >> better >>> names (maybe 'PlusInfinity' and 'MinusInfinity'?). Just leave None >> alone, >>> please. >> >> This doesn't only apply to numeric comparisons. In Python 2 you >> can compare None with any kind of object and it always sorts first, >> based on the intuition that nothing is less than anything :-) >> > I still think that relying on your intuition is not the right way for > Python. Refuse the temptation to guess.
Hmm, are you sure ? There should be one-- and preferably only one --obvious way to do it. and then Although that way may not be obvious at first unless you're Dutch. which directly relates to: changeset: 16123:f997ded4e219 branch: legacy-trunk user: Guido van Rossum <gu...@python.org> date: Mon Jan 22 19:28:09 2001 +0000 summary: New special case in comparisons: None is smaller than any other object :-) >> FWIW, I don't think we need to invent a new name for it, just add >> an appropriate tp_richcompare slot to the PyNoneType or readd the >> special case to Object/object.c. This would also aid in porting >> existing Python 2 code to Python 3. > > Based on your comment, SortsFirst and SortsLast sound like good names ;-) > > These would be "universal sortable objects", that could be compared to any > other type. Of course, it's easy to add a new type for this, but a lot of Python 2 code relies on None behaving this way, esp. code that reads data from databases, since None is the Python mapping for SQL NULL. -- Marc-Andre Lemburg Director Python Software Foundation http://www.python.org/psf/ _______________________________________________ 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