[Python-Dev] Tagged integers

[Phillip J. Eby]

At 01:41 PM 7/16/04 +1200, Greg Ewing wrote:
>James Y Knight <foom at fuhm.net>:
>
> > The only thing you can do with an arbitrary PyObject * is access its
> > ob_type or ob_refcnt. Anything else will break with objects today.
>
>One other thing that would break is testing whether
>an object is an integer and then accessing fields of
>the integer object directly. Not that this seems a
>likely thing for people to do, though.

I guess we'd need to XXX-ify ob_ival as well, then.  There's already a 
PyInt_AS_LONG macro that should be used for that purpose.

So far, the -1000 from Guido makes it seem unlikely this'll get accepted, 
though.

I am sort of curious, though, as to how many extension modules would 
actually require changes to support this.  A bit of grepping through the 
source of several I use, seems to indicate that it isn't that common to use 
ob_type, and it's most likely to appear:

1) in the setup of a type object, setting the type's type to type  :)  (by 
far the most common, and not a usage that needs to be changed)

2) in the definition of a macro that verifies the type of an extension object

3) in allocation/deallocation routines

Only uses 2 and 3 would need to be changed, and they tend to be quite isolated.

By contrast, I didn't find any ob_ival uses, and the only place I saw 
direct use of ob_refcnt was in some Pyrex-generated tp_dealloc code.

Of course, my sampling was hardly statistically valid.  I imagine the real 
extensions to check out would be things like SciPy, Numeric, PIL, wxPython, 
Boost::Python, win32all, PyCrytpo, etc.  That is, widely used packages of 
very large size.

If I understand correctly, extensions have to be recompiled to move between 
Python versions anyway, and compared to some previous C API changes, this 
one actually seems pretty minor.  Extensions like 'kjbuckets' that were 
written for early 1.x Python versions definitely needed work to make them 
build with the later 1.x and 2.x versions.