[Python-Dev] python 3 niggle: None < 1 raises TypeError

[M.-A. Lemburg]

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/