Mailing List Archive

None inconsistent
Pardon the repetition (if this is repetitive). I have posted
this message three times but have yet to see it appear on the
newsgroup.

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

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.)
(2) Can we count on it staying this way forever? (I hope so.)
(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)

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.

Thanks,
Manus


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
None inconsistent [ In reply to ]
[mjhand@concentric.net]
> 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