On 18.02.2014 05:25, Tim Peters wrote: > [M.-A. Lemburg] >> Now, the choice to have None compare less than all other objects >> may have been arbitrary, but IMO it was a good, consistent and >> useful choice. > > Possibly useful for some apps, sure. Not for my apps. For example, > when I initialize an object attribute to None in Python 3, I _expect_ > I'll get an exception if I try to use that attribute in most contexts. > It makes no more sense to ask whether that attribute is, say, less > than 3, than it does to add 3 to it. The exception is most useful > then. More often than not, it was annoying to me that Python 2 > _didn't_ whine about trying to compare None.
Yes, I see your point, but please also consider that None is used in database applications as natural mapping for SQL NULL and in other data processing applications to mean "no value". This is not garbage data, it's just missing information for a particular field and you can still happily process such data without having the information for these fields as values (indeed in some cases, the information whether a field has a value or not is important, e.g. for data validations and to cross check entries). You do still want to be able to sort such data, but as it stands, Python 3 doesn't allow you to, without adding an extra layer of protection against None values deep inside the structures you're sorting. >> So why not bring it back > > A huge barrier is (or should be) that Python 3 is over 5 years old > now. Fiddling with the semantics of basic builtin types was possible > - and even welcome - 6 years ago. Now they really shouldn't be > touched in the absence of a critical bug, or a wholly > backward-compatible (with Python 3) addition. > >> and perhaps this time in a way that actually does work consistently for >> all Python objects by implementing the tp_richcompare slot on >> PyNoneType objects and documenting it ?! > > Something to suggest for Python 4, in which case I'll only be -0 ;-) Well, like I said: we'd be making something work again that has worked before and only remove a failure case. The barrier for entry should be lower in such a case. This is similar to bringing back the u"" literals. Those used to cause a SyntaxError and now they no longer do. Even better: we have a chance to properly document the behavior this time around and make it consistent all the way. The alternative would be adding a new singleton to mean mostly the same thing as None, but having the property of comparing less than all other objects and then recommend its use in the DB-API for Python 3 applications... which would break a lot of existing DB-API based apps of course... which is the reason why I'm advocating for changing None instead :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Feb 18 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/ _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
