[Python-Dev] Re: Class/type dichotomy thoughts

M.-A. Lemburg mal@lemburg.com
Wed, 08 Nov 2000 21:34:49 +0100

Jack Jansen wrote:
> > > In other words, what does this new type_id thing
> > > actually *mean*?
> >
> > For the interpreter it means that it can assume the type
> > interface to be binary compatible to the "original"
> > type, e.g. by setting the flag to say PyDict_TypeID
> > the type assures that all PyDict_*() APIs will work
> > on the type -- basically the same thing as PyDict_Check()
> > does now except that the type object needn't be the same
> > anymore.
> I would be _very_ happy if this single type_id could somehow be
> replaced by an array, or a bitset.

I guess a bit array would be a possibility...

#define PyList_Check(obj) ((obj)->ob_type->\
cap_slot could be set at type object creation time using
some Python slot id generator (a function which outputs integers
up to the maximum length of the capabilities array and raises
a Py_FatalError() if this limited is excceded).

> I have a lot of types in MacPython that are acceptable to the APIs of
> other types, a sort of poor-mans-inheritance scheme. For instance, all
> operating system calls that accept a MacOS WindowPtr will also happily
> accept a DialogPtr. Major magic is needed to get this to work
> reasonably in Python, and the Python user can still accidentally mess
> up the refcounting scheme and free things s/he isn't aware of.
> As the number of types in a given run of the interpreter appears to be
> limited (am I right here?) and type-identity-tests are valid within a
> single interpreter run only (am I right here?) 

Right * 2

> an API like
>   typeindex = Py_TypeToTypeIndex(typeobject);
> which would use a dictionary as storage for the mapping and generate
> the index numbers on the fly would do the trick. Call it once during
> module initalization and the
>   Py_ISOBJECTCOMPATIBLEWITH(object, typeindex)
> macro would be a oneliner to test the bit in the set.
> A few hundred bits in the set would get us a long way, I guess.

One thing I'm unsure about is whether changing cap_slot ids
between runs of the interpreter are a good idea. Also, I think that
the basic types should be given constant cat_slot ids to enhance
performance (the id generator could be made to start at say 10 
and the basic types be fixed in the range 0-9).

Marc-Andre Lemburg
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/