boost::python, returning new PyObject references

[Arnaldur Gylfason]

David,

I've taken a brief look at mpl ( understand parts. Almost for_loop but not
quite. Hierarchy generators left).
I think I would like some time to experiment and learn before contributing
in this area (the generator_ - object<...> code).
That means I won't be comfortable developingcode like this until maybe in a
few months.

I have a few comments regarding your generator code though.

a)
It relies on type casting to get to the PyObject. That way all generators
are just interfaces with no data but type_cast the this pointer to access
the PyObject they need.
Why not type cast to a object_base* and call get() / reference() ?
That way we can get to the PyObject through get() and override it when
needed (proxy).
You use the template parameter T  and lets the use_generator pass the
parameter to it (why don't we just explicitly type cast to object_base* and
get rid of T ?).
The const proxy issues could be handled through operator[]() and operator[]
() const as before:

struct getattr_generator
{
    template <Base = empty>
    struct type : Base
    {
        void validate()
        {
            PyObject* self = static_cast<object_base*>(this).get();
            if (!self->ob_type->tp_getattr && !self->ob_type->tp_getattro)
                throw something;
        }

        // maybe this should return object<>, I don't know.
        ref getattr(char const* name)
        {
            object_base* self = static_cast<object_base*>(this);
            return ref(PyObject_GetAttrString(self->get(),
name));
        }
    };
};

object<...> would inherit from object_base + generated hierarchy for the
generator list.


b)
sequence is a type_list of generators.
We would therefore use object<sequence> instead of sequence ??


c)
getting a unique generator list would have to be more advanced.
Let's say we combine sequence and number. Both define addable but not in
the same way.
We have to choose 1 or at least somehow remove any ambiguity.
Similar remarks go for using ints as keys in mapping and then combining
with sequence.

d)
Defining generators at this granularity makes it possible to have object
interfaces that are complete
and guarantee that all operations/methods are supported, which is what you
are aiming for.
On the other hand this is a bit cumbersome.
How about developing the hierarchy we were approaching:

object_base
abstract_object : object_base

callable : virtual abstract_object
(slicable : virtual abstract_object)
sequence : slicable

mapping : virtual abstract_object
number : virtual abstract_object

object : callable , sequence , mapping , number

list : sequence


then later offer try the meta-template approach with generators and offer
something like object<...>
that has more fine-grained granularity and more control/type-checking?
(discern between object and object<...> though).


For immutable types like tuple we have to have non-const objects that only
allow const methods
from interfaces like sequence. Have to figure a clean way for this, so
tuple can inherit from
immutable sequence.

What do you think?

Cheers

Arnaldur