[Python-Dev] PyInstance_Check() and new-style classes (original) (raw)

Eric Wilhelm ewilhelm at sbcglobal.net
Mon Jul 12 18:48:25 CEST 2004

The following was supposedly scribed by

Michael Hudson

on Monday 12 July 2004 09:14 am:

Eric Wilhelm <ewilhelm at sbcglobal.net> writes:

For starters, the process-of-elimination way of determining the type is pretty clunky, and only works on classes which have subclassed the 'object' type (not lists, tuples, strings, etc.) That just restates the problem :-) Why do you care if a given object is an instance of a builtin type or not?

I only care that it is an instance of a user-defined class, so that the Inline::Python module can bless a reference to its memory address, which then allows Perl to locate the bound methods in the symbol table.

but checking the TPHEAPTYPE flag in tpflags may go some way towards one.

I'll have to look into this. I'm not sure what that would tell me. Well, it tells you whether the type objects memory lives on the heap or is a static object from the C point of view. This is potentially interesting because it being true is /almost/ synonmous with 'user-defined type'.

Are there some other serpents lurking in that /almost/ besides the "C-extensions" one? If not, I think we can accept the simple work-around of defining an empty python subclass (e.g. 'pass') (see my reply to Phillip's post.)

What you do with subclasses of builtin types like strings is a difficult question. I wouldn't presume to know the best thing to do here.

Ideally, I'd like them to be a proper Perl reference to a Perl scalar containing the string. Though this is really more important for tuples and lists than it is for strings. As it is, my new code will identify anything which comes from a classic or new-style class (with the caveat (supposedly) that the new-style class was not created as a C extension) and return a reference to a scalar which contains the memory address of the object (be it an instance or a type.)

Yes, this means that classes which subclass tuples or lists will appear as opaque objects in Perl (accessible only via their methods), but I think that's acceptable.

Thanks, Eric

"It ain't those parts of the Bible that I can't understand that bother me, it's the parts that I do understand." --Mark Twain

More information about the Python-Dev mailing list