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

[Dieter Maurer]

Tim Peters wrote at 2006-6-21 18:58 -0400:
> ...
>[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.

Yes, of course :-)

It is similar to the situation when you create an int
in a pickle on a 64 bit box, unpack it on a 32 bit box
and then store it in a C "int". In may not work...


> ...
>Also flesh out what benefits you think might be gained.

You pointed out an inconsistency between the BTree implementation
and the Python mapping of its "int" to C.

The major benefit would be to remove this inconsistency:
the ("Ix/xI"-)BTree could represent correctly what it promisses:
handle all Python ints (independent on architecture) -- at
least as you stay on the same architecture.

True, you could not necessarily move BTree pickles around
architectures -- but currently, you already fail (miserably: without
exception by simply loosing the higher order bits) on one
architecture. After the change, you will (hopefully) at least
get a meaningfull exception.

> ...
> Anything else?  It's usually not a good idea to create
>platform-specific differences.

You have this difference already: on some platforms
Python ints are 64 bit wide....

> ...
>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".

You will as soon as you pass it on to C functions -- e.g. "BTrees" ;-)



-- 
Dieter