[Python-Dev] python 3 niggle: None < 1 raises TypeError
mal at egenix.com
Mon Feb 17 15:30:39 CET 2014
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:
>> 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
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.
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
More information about the Python-Dev