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

[Gustavo Carneiro]

On 17 February 2014 11:43, M.-A. Lemburg <mal at egenix.com> wrote:

> 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 :-)
>
> I still think that relying on your intuition is not the right way for
Python.  Refuse the temptation to guess.


> 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.



>
> --
> 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/
>



-- 
Gustavo J. A. M. Carneiro
Gambit Research LLC
"The universe is always one step beyond logic." -- Frank Herbert
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20140217/7e94223c/attachment.html>