Terry Reedy wrote:
M.-A. Lemburg wrote:
I think the special case for None should be readded to Python 3.0.
Quick summary of thread that MAL started on Python-3000-dev list:
Once upon a time, 0 < None was true.
When rich comparisons were added, None < 0 (and *most* other things)
become true as an intentionally undocumented implementation detail.
The None rule only applies for sure when None controls the comparison:
ob < None is true or undefined if type(ob) says so.
Guido's pronouncement: "In short, I'll have None of it."
summarizing
We're not going to add the "feature" back that None compares smaller
than everything. It's a slippery slope that ends with all operations
involving None returning None -- I've seen a proposal made in all
earnestness requesting that None+42 == None, None() == None, and so
on. This Nonesense was wisely rejected; a whole slew of
early-error-catching would have gone out of the window. It's the same
with making None smaller than everything else. For numbers, you can
already use -inf; for other types, you'll have to invent your own
Smallest if you need it.
tjr
This still doesn't explain why None should not be comparable to itself.
--
Robin Becker
--
http://mail.python.org/mailman/listinfo/python-list
