boost::python, returning new PyObject references

David Abrahams david.abrahams at rcn.com
Sun Jan 6 19:21:40 CET 2002


----- Original Message -----
From: "Arnaldur Gylfason" <arnaldur at decode.is>

> This latest design is where I was heading but it was just materializing
> now, so I don't blame you for being confused.
> It is not perfect though.
> A part of the abstract_object interface applies to most/all objects, e.g.
> str().

Yes, I was trying to make that point in a previous message, e.g. that List
is not just a Sequence but also an Object.

> In this design number, list etc. would not have these methods.

Well, you could derive list from sequence and object, right?

> Only abstract_object and object would have them (plus the proxies).
> Using the private inheritance design could fix that.
> I am not sure if this is a problem though.
> What do you think?

I think that if we are going to respect the Python concept model, we must
derive all types known to have str() from abstract_object as well as the
other concepts they might model.

> Regarding attributes for list, I think the list interface has everything
> one needs for working with a list,
> so it doesn't have to inherit from any of the generic interface classes.

It seems to me that list should just inherit sequence and abstract_object,
and supply the appropriate constructors and accepts() function. All the rest
of the interface would be taken care of by the base classes.

> > Before moving along, you should probably take a moment to look at
> > http://cxx.sourceforge.net/. The object interface is one of CXX's
central
> > features, so it may be more fully-developed than what we have in
> > Boost.Python. It would be a shame to overlook something which CXX has
> > already handled in a superior way.
>
> True. I have given it a look and I think we should go carefully over it
> before completing the interfaces.
> I personally think though, that the design we're aiming at is superior.

:^) :^)







More information about the Cplusplus-sig mailing list