[Zope3-dev] buildbot failure in Zope3 trunk 2.4 FreeBSD tmiddleton

[Tim Peters]

[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 ;-)