Re: accessing the python type system

Stefan Seefeld <seefeld@xxxxxxxxxxxx> writes:

> David Abrahams wrote:
>
>>>What about a 'type object' similar to 'type_info', i.e. with
>>>a 'name()' accessor and comparison operators ?
>> Well, if you have isinstance you don't need that.
>
> but 'isinstance' requires a type object to be passed, whether 'name()'
> would permit to query that (or a 'stringified form' of it) from the
> object in question.
>
>> In principle, there's no reason we shouldn't have something like you
>> propose, only it should be a wrapper around Python's 'type' just the
>> same way that boost::python::dict is a wrapper around Python's
>> 'dict'...
>
> that's precisely what I have in mind.
>
>> ...but once you start go go down that road you get in trouble.  Python
>> makes type(x) return a reference to x.__class__ (unless x is a
>> "classic" instance, in which case it returns "instance").  Because
>> type(type(x)) also has to work (get x's metatype), it can't have a
>> regular copy constructor.
>
> Sorry, I don't understand that. 

If boost::python::type is a class like boost::python::dict is, then
type(x) is an instance of that class (OK so far) but type(type(x))
invokes type's copy constructor.  Those are just the syntax rules of
C++.  In order to be consistent with Python, type(type(x)) != type(x)
for most x,

    >>> type([])
    <type 'list'>
    >>> type(type([]))
    <type 'type'>

but that implies type's copy constructor doesn't make equivalent
copies (very bad in C++).

> the Python C Api provides 'type objects', so ultimately I would
> arrive at a single root of that 'instance' <-> 'type' tree

That makes no sense to me.  What is travelling up the tree to arrive
anywhere?

> , i.e. the top node is a unique type (a 'type type', actually). 

Yes, that's true but irrelevant AFAICT.

> If I can't copy it there should be a (possibly hidden) global
> instance (singleton ?)  that is referenced each time I access it, or
> else I make copies of it.

That's what I'm saying below

> In any case the key is to define what 'equal' or 'identity' means.

No, it's very clear what it means for two types to be identical.  They
have to be the same object.

>> When copies of an object are not equivalent to the original in C++
>> it plays havoc.
>
> yeah, so we need a well defined concept of comparison.

I don't think that's relevant, but it's already well-defined

    >>> list < tuple
    1
    >>> type([]) < type(())
    1

>> I guess 'type' would have to be an instance of a class derived from
>> boost::python::object, whose unary function call operator returns its
>> argument's type.  I wouldn't want a 'name()' function because Python
>> type objects don't have that:
>
> agreed. I would be a concenience only.
>

Patches welcome,
-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com