[ZODB-Dev] RE: ExtensionClass/Persistent and __cmp__ is tricky

[Tim Peters]

I want to cut to the chase here (I really don't have time for more now --
sorry!):

[Tim]
>> It also doesn't make much sense to compare a Foo against an integer.

[Christian Reis]
> Maybe not, but it does work for `normal' instances. Should I raise a
> TypeError instead in my __cmp__() definition?

If I understand what you're after, you're trying to use persistent objects
as keys in BTree-based data structures.  If so, one of the other rules at

    http://www.zope.org/Wikis/ZODB/guide/node6.html

is

    Within a single btree-based data structure, use objects of a single
    type as keys.  Don't use multiple key types in a single structure.

If you want to make life predictable, stick to that rule, and then yes,
since you then *intend* that your BTree have keys of a single type, you'd be
doing yourself a huge favor by raising an exception whenever it's possible
to do so during a mixed-type comparison.

Jim took a stab at explaining what he thought was going on during mixed-type
comparisons involving ExtensionClass objects, and that explanation didn't
match all the behaviors you saw either.  So just take it as a fact that
nobody understands all the behaviors you're stumbling into when playing with
mixed-type comparisons, and avoid them instead.

> I'm unsure of the `correct' semantics here, more than anything.

Then settle for useful semantics <wink>.

> ...
> I expected consistency when comparing with basic types; sorry if I
> wasn't clear enough. However, if the correct policy is to raise a
> TypeError, that's fine (and simpler) with me.

For your app, those appear to be the useful semantics.

> ...
> It's showing to be a bit embarassing but highly enlightening
> (as all newbie things are).

To the contrary, how mixed-type comparisons work in all cases when an
ExtensionClass is involved is beyond wizards at this time.  I'll claim
without proof that how mixed-type comparisons work with Python classes is
also beyond wizard prediction in all cases:  the implementation of
comparison in Python is crushingly complicated.  Life here is easier in
Python 2.3 -- or, it would be, if 2.3 weren't also striving to be compatible
with the mass of pre-2.3 comparison rules.