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

[Michael Hudson]

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 
> PyInstance_Check(), 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 TP_HEAPTYPE flag in tp_flags 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