boost::python, returning new PyObject references

Arnaldur Gylfason arnaldur at decode.is
Wed Jan 9 18:36:36 CET 2002



> Yes, that sounds reasonable... as long as people don't try to slice a
> sequence.
>
> Or, maybe we want the ability to impose some kind of checking mask, so
that
> when people say "sequence" it has all of the obvious sequence interface,
but
> only enforces "indexable", and might throw if something is unsupported.

Sounds good.
The general case has to be easy. OK to have the option of total
fine-grained control when needed.


> I would always use the Python dispatching method unless we know the
concrete
> type of the object. For example, we could have specializations of
> indexable_generator for when T is list.

Sounds interesting. Maybe the way to go.


> > We could solve some issues like e.g. sliceable, but a number that does
not
> > define 1 operation like multiplication:
> > The user would have to be aware of that.
>
> OK. I think it would be good to do it in terms of the concepts we've been
> working with, though. The generators, for example, will make it much
easier
> to transition to a type_list-configurable system. We could imagine a
> protocol like this one:
>
> template <class T, bool checked, class Base>
> struct indexable_generator : Base
> {
>    ...
> };
>
> where "checked" determines whether the capability is enforced at
> construction time. Then you can define your sequence, mapping, number,...
> and concrete list, dict, integer... types in terms of them

Sounds reasonable. Would we add the type member template then when starting
with mpl or is it not necessary for meta-programming?


> Yes, I was thinking about that but didn't address it. It is handled
fairly
> easily with a templated constructor in object<>. You do need to
> STATIC_ASSERT that the capabilities are a subset. Easy enough using mpl.
>
> However, since the capabilities will remain relatively static, you might
> think about a simpler approach for now which uses a collection of
> BOOST_STATIC_CONSTANTs in a bitmask arrangement. Each generator might
define
> its bitmask values, and they would appear combined in the most-derived
> class.

Don't quite get it. Sorry.


> > It seems to me then that the objects are not connected then (apart
> > inheriting from individual generators, so they both pass as
> > indexable_generator etc.)
>
> I don't get what you're saying here.

Has to do with the inheritance above.
object<A,B,C>:
o == object<A,B,C>

empty - A<o> - B<o> - C<o> - o

object<A,C>:
o2 == object<A,C>

empty - A<o2> - C<o2> - o2

What is the relationship between o and o2?









More information about the Cplusplus-sig mailing list