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 _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
