[Zope3-dev] possible bug in catalog code

[Tim Peters]

[Dieter Maurer]
> 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):
...     pass
>>> c = C()
>>> None < c  # None is less than c
True
>>> type(None).__name__ < type(c).__name__ # although its type name is >
False

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
False
>>> set() != 2
True
>>> 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"
>  methods.
>
>  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>.