[Python-3000] None in Comparisons

[M.-A. Lemburg]

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

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

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,
nothing more.

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

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

Fair enough.

-- 
Marc-Andre Lemburg
eGenix.com

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