[Python-Dev] python 3 niggle: None < 1 raises TypeError

M.-A. Lemburg mal at egenix.com
Mon Feb 17 12:43:25 CET 2014


On 17.02.2014 12:23, Gustavo Carneiro wrote:
> On 17 February 2014 11:14, M.-A. Lemburg <mal at 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 :-)

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.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Feb 17 2014)
>>> Python Projects, Consulting and Support ...   http://www.egenix.com/
>>> mxODBC.Zope/Plone.Database.Adapter ...       http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________
2014-02-12: Released mxODBC.Connect 2.0.4 ...     http://egenix.com/go53

::::: Try our mxODBC.Connect Python Database Interface for free ! ::::::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
               http://www.egenix.com/company/contact/


More information about the Python-Dev mailing list