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

[M.-A. Lemburg]

On 17.02.2014 14:29, Gustavo Carneiro wrote:
> On 17 February 2014 12:30, M.-A. Lemburg <mal at egenix.com> wrote:
> 
>> On 17.02.2014 13:19, Serhiy Storchaka wrote:
>>> 17.02.14 13:56, M.-A. Lemburg написав(ла):
>>>> Yes, but that's not the point. Unlike strings or other mixed types that
>>>> you cannot compare, None is used as placeholder in data processing as
>>>> special value to mean "no value available".
>>>
>>> Isn't float('nan') such placeholder?
>>
>> You can easily construct other such placeholders, but None was intended
>> for this purpose:
>>
>> http://docs.python.org/2.7/c-api/none.html?highlight=none#Py_None
>>
>> """
>> The Python None object, denoting lack of value. ...
>> """
>>
>>>> You intentionally use such values in programming. It's not a bug to
>>>> have None in a data list or as value of a variable.
>>>
>>> You can't have None in array('f'), you can't add or multiply by None.
>> Relation operators don't looks
>>> an exception here. Applying sorted() to a list which contains numbers
>> and Nones makes as much sense
>>> as applying sum() to it.
>>
>> Of course, you cannot apply any operations with None - it doesn't
>> have a value -, but you can compare it to other objects and it provides
>> a consistent behavior in Python 2. Python 3 is missing such an object.
>>
> 
> I agree with you that Python 3 could use such an object.  Just don't make
> it the default.  Leave None as it is.
> 
> Also I agree that my previous naming suggestions are bad.  What we need is
> only one (or two) additional object whose main semantic meaning is still
> "no value", but which also adds a meaning of "comparable".  Then it's a
> matter of choosing a good name for it, with lots of bikeshedding involved.
>  Just lets not change None only because we're too lazy to discuss a proper
> alternative name.  Also this use case is not _that_ common, so it's ok if
> it has a slightly longer name than None.
> 
> Also think of the implications of changing None at this point.  It would
> allow us to write programs that work Python >= 3.5 and Python <= 2.7, but
> fail mysteriously in all other versions in between.  What a mess that would
> be...

Yes, that's unfortunately true.

If you regard this as bug in the Python 3 series, we could still fix
it for 3.3 and 3.4, though. After all, we'd just be removing an unwanted
exception and not make already working Python 3 applications fail.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Feb 17 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/