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

[Jack Jansen]

> > 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 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?) 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.
--
Jack Jansen             | ++++ stop the execution of Mumia Abu-Jamal ++++
Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++
www.oratrix.nl/~jack    | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm