[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