Re: Re: accessing the python type system

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. the Python C Api provides 'type
objects', so ultimately I would arrive at a single root of that
'instance' <-> 'type' tree, i.e. the top node is a unique type
(a 'type type', actually). 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. In any case
the key is to define what 'equal' or 'identity' means.

> 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 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.

Regards,
                Stefan