> The current Python falls back to order by type name and than by id.
Except that in current CPython releases, None is an exception to that, like
>>> class C(object):
>>> c = C()
>>> None < c # None is less than c
>>> type(None).__name__ < type(c).__name__ # although its type name is >
In some earlier CPython releases, None was not an exception to that.
> I do not expect this to change again.
I do, but perhaps not before "Python 3000". The trend among newer
builtin Python types is to allow mixed-type comparison _only_ when the
comparison operator is == or != (and objects of different types
compare "not equal" then). For example, the various newer datetime.*
and set types work that way; e.g., try comparing a set to an integer
in Python 2.4:
>>> set() == 2
>>> set() != 2
>>> set() < 2
Traceback (most recent call last):
File "<stdin>", line 1, in ?
TypeError: can only compare to a set
It's almost certainly the case, e.g., that trying to compare a str
with a float will eventually do the same kind of thing.
> However, there is an additional reason not to put "None" into a BTree.
> Its interface has a weekness in its "keys", "values", "min" and "max"
> E.g. in "keys(min,max)", "min=None" or "max=None" mean: no restriction.
> Therefore, they cannot distinguish between a "None" stored in the
> BTree itself and the use of "None" as "no restriction".
Yup, except I wouldn't call it a weakness. Since BTrees should not be
used with mixed key types anyway, and None is only value of type
type(None), the only BTrees having None as a key should be empty or
contain a single key (namely, None). Range search on trees with 0 or
1 elements isn't particularly difficult <wink>.
Zope3-dev mailing list