None inconsistent

Tim Peters tim_one at
Fri Jun 11 03:22:37 CEST 1999

[mjhand at]
> Pardon the repetition (if this is repetitive).  I have posted
> this message three times but have yet to see it appear on the
> newsgroup.

First time I've seen it <wink>.

> In 1.5.1, "None" was "less" than all numbers:
> >>> 0 < None
> 0
> >>> sys.maxint > None
> 1

Yes, "incomparable" objects were compared first by the *string* name of
their type in 1.5.1, and as strings "None" < "int".  An accident, really.

> In 1.5.2, "None" became "greater" than all numbers:
> >>> 0 < None
> 1
> >>> sys.maxint > None
> 0
> I have three questions about this:
> (1) Was this change made intentionally?  (I hope so.)

What happened to None was pure accident, but the rules were deliberately
changed to treat all builtin numeric types (int, long, float, complex) as
having string name "", i.e. an empty string.  Else e.g. because, as strings

    "int" < "list" < "long"

we also had

    42 < [42] < 42L

return true while

    42 < 42L

returned false.  Python is happy to let you create your own non-transitive
comparisons, but didn't want to set a bad example <0.9 wink>.

In 1.5.2 they both return false.

> (2) Can we count on it staying this way forever?  (I hope so.)

The language doesn't define what happens when doing silly <wink>
comparisons, beyond promising consistency involving comparisons of objects
of builtin types.  So, no, in theory you can't count on it.  In practice,
the change in 1.5.2 achieved the consistency it was aiming for, so as a
practical matter it's unlikely to change again.

> (3) When will the starship be updated to use 1.5.2 by default?
>     (/usr/bin/python == 1.5.1, /usr/local/bin/python == 1.5.2b2)

Beats me -- bring it up on the starship crew mailing list.

> I absolutely LOVE that "None" is accepted as a valid argument in
> min(), max(), and cmp(), but I would like it to behave consistently.
> The 1.5.2 way is best for my code.  Please tell me it will stay
> that way forever.

I won't lie without better financial inducement than that.

besides-only-guido-is-eternal-ly y'rs  - tim

More information about the Python-list mailing list