Re: Re: accessing the python type system

David Abrahams wrote:

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

That's where I'm lost. I don't see the copy constructor involved here.
Assuming boost::python::type IS-A boost::pyton::object, and there is
a way to generate a boost::python::type for each boost::python::object
("it's type"), which means you would be able to hold a 
boost::python::type describing another boost::python::type's type (i.e.
the result of 'type(type([]))'.

What do you want to copy here ?
Or in diagram form:

 py_object       ->       py_type
    ^                       ^
    |                       |
python::object        python::type

holding a python::object, you can construct a python::type object
by accessing the 'py_type' object with 'PyObject_Type(object.ptr())'
and wrapping this into a newly created python::type object.

That would work no matter whether the original python::object was
actually a type or an instance.

Then you could define comparison operators like:

bool operator == (const python::type &t1, const python::type &t2)
{
  return t1.ptr() == t2.ptr(); // assuming only one python object exists
                               // per type
}

and

bool operator <= (const python::type &t1, const python::type &t2)
{
  return PyObject_Subclass(t1, t2);
}

etc....

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

sorry for not being clear. I was drawing a tree in my mind where
parent nodes are types and child nodes are instances of those types.
It would be a tree (well, actually onle two levels deep) since the
root node would be a 'meta type', its children would be 'types', and
their children would be 'instances'. All I meant to say was that you
either walk up that tree when calling 'type(object)', or you stay
where you are (i.e. the 'type' operator is idempotent when applied to
a 'meta type').

What am I missing ?

Regards,
                Stefan