[Christian Reis]
>  (I suppose I push these things in annoying ways.)

I don't think so.  I think it's more that you're playing in dark corners
that nobody else wants to visit.  For example, it's unlikely my boss will
tell me to devote days to this <wink> .

The docs I pointed you at before strongly recommend using simple, immutable
values, with well-defined __cmp__ methods, as BTree keys.  When you go
beyond that, you're trying things nobody understands.  For example, I have
no idea how a PersistentMapping will or won't compare itself against a
Python dict, and I wager nobody else does either.

>  [various examples of trying to use Python dicts and PersistentMapping
>   objects as BTree keys, and of trying to use one of those types as
>   a key when setting a value, then retrieving via the other type]
>  ...

You don't need BTrees to find confusion here.  For example, this is enough:

> >> d = {1:1, 2:2}
> >> p = PersistentMapping(d)

> >> p == d
1
> >> d == p
0
> >>

I expect you'll see the same two results, and (of course) they're
inconsistent.  (They're also inconsistent under the covers, then, when the
BTree code invokes comparison operations.)

> >> p < d
0
> >> d > p
1
> >>

I expect you'll see 0 for the first result there, but that the second result
may vary across platforms.  It's obvious <wink>  to me that when the dict is
on the left-hand side of a comparison, it compares itself against a
PersistentMapping by memory address.  When the PersistentMapping is on the
left-hand side, it compares its hidden Python dict to the other dict, and
Python dict comparison is well-defined.

>  The check() module indicates it works okay.

check.check() can only confirm that the BTree hasn't become internally
insane.

>  I've tried to track this down but I'm not having a large measure of
>  success. It *seems* to me that the problem is PersistentMapping's
>  __cmp__ method is not being called consistently, but ever since Tim
>  warned me of mixed-type comparisons I've been reluctant to spend a
>  long time staring at code when I see these issues.
> 
>  Should I just try and band-aid it in my code?

I suspect you'd have more luck if you explained what you're trying to
accomplish, so that people could suggest other ways to get there.

Since mixed-type comparisons here are demonstrably inconsistent, you would
have to rely on brand new releases of ZODB and/or of Python too(!) to
straighten those out.  You would also have to convince someone it's worth
their time to try to repair the inconsistencies in ZODB and/or in Python.
That would be an even harder sell than you're imagining, because the
implementation of comparisons right now is so bloody complicated that
there's a very strong chance any change will break someone else's
currently-working code.

So, IMO, the only realistic choice is to find a different way to solve your
real problem (I don't know what that is, I only know you're not going to
solve it via what you're trying to do now).


_______________________________________________
For more information about ZODB, see the ZODB Wiki:
http://www.zope.org/Wikis/ZODB/

ZODB-Dev mailing list  -  ZODB-Dev@[...].org
http://mail.zope.org/mailman/listinfo/zodb-dev