[Python-Dev] Tagged integers

Guido van Rossum guido at python.org
Thu Jul 15 03:42:54 CEST 2004


> >-1000 here.  In a past life (the ABC implementation) we used this and
> >it was a horrible experience.  Basically, there were too many places
> >where you had to make sure you didn't have an integer before
> >dereferencing a pointer, and finding the omissions one core dump at a
> >time was a nightmare.
> 
> That certainly seems like it would be so, except...  doesn't every bit of 
> Python code that's doing anything *other* than accessing ob_type or 
> ob_refcnt have to first check if ob_type is the type that code is looking 
> for anyway?
> 
> And, don't the vast majority of accesses to ob_type and ob_refcnt occur 
> inside Python core API macros and functions anyway?
> 
> If in addition to Mr. Knight's patch, ob_type and ob_refcnt were renamed so 
> as to break any existing direct access in the core or extension modules, 
> upgrading them to use Py_GETTYPE and Py_GETREF would be straightforward 
> because one would "find the omissions" one *compilation error* at a time.
> 
> Further, renaming those fields to something like 'XXXusePy_GETTYPE_instead' 
> would provide a built-in hint that you weren't supposed to use the field 
> directly.  :)
> 
> An additional trick: make it so that the macros for defining new object 
> types still create an ob_type field, but let PyObject * point to the 
> structure with the XXX fields.  Thus, you can only access ob_type directly 
> if you've already cast to a non PyObject * type.  (i.e., you've already 
> used an appropriate PyXXX_Check on that variable and would like to use it 
> as a regular object now).
> 
> Naturally, the issues of portability and what impact Mr. Knight's approach 
> has on non-integer code would need to be taken into consideration as well, 
> but it seems to me that this approach *could* be made type-safe, at the 
> cost of some initial pain to update the approximately 640 uses of 'ob_type' 
> in the current source base.

Sorry, I'm still not convinced that it's worth to break all the 3rd
party extensions that undoubtedly are doing all sorts of things that
strictly speaking they shouldn't do.

And what about all the extra code generated for Py_DECREF and
Py_INCREF calls?  These now all contain an extra jump.  Horrors!

--Guido van Rossum (home page: http://www.python.org/~guido/)



More information about the Python-Dev mailing list