[Python-Dev] python 3 niggle: None < 1 raises TypeError
ncoghlan at gmail.com
Mon Feb 17 23:25:27 CET 2014
On 17 Feb 2014 22:25, "M.-A. Lemburg" <mal at egenix.com> wrote:
> On 17.02.2014 13:12, Nick Coghlan wrote:
> > On 17 Feb 2014 21:15, "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.
> > This is the first I've ever heard of that sorting behaviour being an
> > intentional feature, rather than just an artefact of Python 2 allowing
> > arbitrarily ordered comparisons between different types. Can you point
> > to the relevant entry in the Python 2 language reference?
> This is not documented anywhere in the language spec, AFAIK. It
> is documented in the code (Python 2.7; Object/object.c):
> default_3way_compare(PyObject *v, PyObject *w)
> /* None is smaller than anything */
> if (v == Py_None)
> return -1;
> if (w == Py_None)
> return 1;
> Note that it's not important whether None is smaller or greater
> than any other object. The important aspect is that it's sorting
> order is consistent and doesn't raise a TypeError when doing an
> ordered comparison with other objects.
Thanks, that's enough to persuade me that it is a good idea to restore that
behaviour (and make it an official part of the language spec) as part of
the "eliminate remaining barriers to migration from Python 2" effort in 3.5.
It will mean that SQL sorting involving NULL values maps cleanly again, and
it's easy enough to use any() to check that container doesn't contain None.
> Marc-Andre Lemburg
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-Dev