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

Michael Hudson mwh at python.net
Mon Jul 12 16:14:00 CEST 2004

Eric Wilhelm <ewilhelm at sbcglobal.net> writes:

# The following was supposedly scribed by # Michael Hudson # on Monday 12 July 2004 08:08 am:

tell me if I'm doing this "the right way" (TM). Why does it matter?  I did actually read the rest of your post, but this failed to leap out at me (apologies if I'm being dumb). 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?

Also, it seems that the type/class unification has broken the API function PyInstanceCheck(), which I think should tell me if I'm dealing with an instance of a builtin type. If not, it seems that there should be some function which allows me to perform this check.

Well, in Python/C API terms "Instance" usually means "instance of old-style class". Apologies, but what you think these functions should do isn't the most reliable of guides :-)

There's no real answer -- there's just not that much difference between user-defined new-style classes and builtin types (part of their appeal!) 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'.

Basically, Perl's "objects" are just bless()ed references. That seems analogous to the direction that Python has gone with the type/class unification, but Perl is a little less formal about objects.

Um. From a knowing-Python-but-not-knowing-much-perl point of view, I wouldn't agree with that statement...

[snippety]

Granted, we could just pass pointers to python objects for everything, but that wouldn't make a very good perl binding, since we'd then have to use $string->append("foo") instead of Perl's builtin $string .= "foo" and I'm not sure yet how we would get to the actual value of $string under that schema.

Seriously, I'd advise to you check for the types you do know how to bridge to perl types -- integers, lists, strings, that sort of thing -- and generically wrap everything else.

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.

Cheers, mwh

-- There are two kinds of large software systems: those that evolved from small systems and those that don't work. -- Seen on slashdot.org, then quoted by amk

More information about the Python-Dev mailing list