[Python-3000] None in Comparisons
mal at egenix.com
Tue Nov 11 14:54:48 CET 2008
On 2008-11-11 14:28, Antoine Pitrou wrote:
> M.-A. Lemburg <mal <at> egenix.com> writes:
>> Why was the special case for None being "smaller" than all other
>> objects in Python removed from Python 3.0 ? (see object.c in Py2.x)
> Because ordered comparisons (<, <=, >, >=) are much stricter in 3.0 than in 2.x.
> In practice, ordered comparisons which don't have an obvious, intuitive meaning
> now raise a TypeError (such as comparing a number and a string).
That's fine. I'm just talking about the special case for None that
has existed in Python for years - and for a good reason.
>> It looks like a bug in Python 3.0 to me, since None is widely used as
>> "n/a" object in Python.
> But why should "n/a" (or "missing", or "undefined") imply "smaller than
> everything else"?
It's just a convention based on viewing None as "nothing" or the
> I understand it might be a case of "practicality beats purity", but this is not
> semantically obvious and can also let bugs slip through (the very bugs that the
> stricter ordered comparison semantics in 3.0 are meant to make easier to
Please note that I'm just talking about that one object, not all
the other cases where comparisons between apples and oranges don't
make sense :-)
> Also there are cases where you'll want something which is *bigger* than
> everything else, not smaller.
Having None compare smaller than all other objects is just a convention,
If there's a need for an object that compares larger than any other
object in Python, we could introduce another singleton for this, but I
don't really see the need.
> (SQL seems to do such a thing with NULL, but SQL isn't exactly a good example
> for programming language design, is it?)
NULLs are a fact in life, not only in SQL, but also in numerics and
statistics. You often don't want a complex calculation or query to
fail just because a few input values are not available.
None has been used in Python for the same purpose in these application
> If it is really useful, I think i would be cleaner and more explicit to add the
> Smallest and Largest constants suggested elsewhere, than reuse a very widely
> used constant (None) for half of the purpose.
Professional Python Services directly from the Source (#1, Nov 11 2008)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
:::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX 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
More information about the Python-3000