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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4