[Tim]
... The problem arises because what _Python_ calls "int" is what C calls "long", but the I-flavor BTree code stores C "int", and C "int" doesn't correspond to any Python type (except "by accident" on 32-bit boxes).
[Dieter]
Why not simply change this, i.e. let "BTree" use what Python calls an "int" (i.e. a "C long"). Of course, we need to be a bit careful, when we load pickles. They might have been written by applications with a longer "C long" than we have.
Flesh out what "a bit careful" means? For example, it would be flatly impossible to create an IIBTree on a 64-bit box and load it _as_ an IIBTree on a 32-bit box then, unless the original values stored all happened to fit in 32 bits. You want to change the concrete type on the fly? Make "IIBTree" an abstract base clase with different concrete subclasses depending on ... something or other ;-)? Also flesh out what benefits you think might be gained. It would allow closing the specific BTree bug mentioned earlier in this thread. Anything else? It's usually not a good idea to create platform-specific differences.
But, this problem we have anyway (independent of BTrees).
Where specifically do you see this problem? Since Python's "int/long unification" PEPs were implemented, I rarely particularly care whether I'm using a Python "int" or a Python "long". Internally, Python works with PyObject* pointers, so it rarely cares either. The entire point of an I-flavor BTree is that it's _not_ general ;-) _______________________________________________ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com