ExtensionClass/Persistent and __cmp__ is tricky
tim at zope.com
Sun Jun 29 18:49:03 CEST 2003
I want to cut to the chase here (I really don't have time for more now --
>> It also doesn't make much sense to compare a Foo against an integer.
> 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
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.
More information about the Python-list