boost::python, returning new PyObject references

Arnaldur Gylfason arnaldur at decode.is
Mon Jan 7 17:35:24 CET 2002


__ You wrote __

I think I am beginning to see why Guido says that an inheritance hierarchy
gets us in trouble: there are too many combinations to create classes for
all of them. Instead, we want some way to combine concepts "on-the-fly". In
other words, you want to be able to write a function that takes a callable
sliceable sequence without first having to create a class which inherits
from all three of these. The only way I can think of to represent that is:

void f(python::object<callable,sliceable,sequence> x)
{
  ...
}


> In view of the discussion I've been wondering about inheritance (e.g.
list
> inheriting from sequence).

I /do/ think inheritance is appropriate for dealing with the concrete
Python
types like List. So for example we might have

class list : public object<sliceable,mutable,sequence...>
{
    ...
};

We'd have to decide what the default properties for object<> are. Probably
everything.

This is a bigger programming challenge than what we've been considering,
but
worth it I think.

_______

I came up with a similar idea some weeks ago (i.e.
object<number,sequence,mapping,...> ).
You mentioned the Andrei's GenScatterHierarchy .

I've looked into this and I don't think GenScatterHierarchy is the way to
go. Maybe something similar.

We can use the same design as in boost::function to have variable number of
parameters.
Problem is some interfaces intersect (e.g. += for number and sequence
etc.).
I was wondering if it was possible to define a INTERSECT macro that can
handle this but am way out of my league here.
It is possible to pull this off using template specialization but the
number of specializations would be high
(exponential explosion).

Cheers

Arnaldur




More information about the Cplusplus-sig mailing list