boost::python, returning new PyObject references

[David Abrahams]

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

> As I mentioned in a follow-up letter I've got now why using the template
> parameter can be better.
> We probably should stick with it.

I know; sometimes it's best to spell things out, though.

>    Precisely. Otherwise, you end up having to create clumsy classes like
>    seqmap
>    to combine fine-grained capabilities.
>
> seqmap is object<sequence,mapping> yes.
> I was wondering if we could have object<sequence_generator>
> and sequence as a typedef to it.

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.

I want users to be comfortable as well as safe ;-)

> Yes. I'll take a look at the python source.
> In some cases we know how to handle things like o[i]: sequence access if i
> is integral, mapping access otherwise.

Not neccessarily:

x = { 1 : 'one', 2 : 'two' }
x[1]

> Combining sequence an mapping in object<sequence,mapping> would have to
> figure that out.
> In a generic solution like this how would we do that?

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.

However, that's an optimization I would leave for later (much).

>    > 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).
>
>    I think it will be problematic, unless we give up on validity checking.
>    How will users manipulate a sequence that turns out NOT to be
sliceable?
>
> We would give up on validity checking (offer the accepts but not calling
it
> in the constructor).
> I know it is not the way you want it, but acceptable for now ??

If it brings real benefits, then a small step is better than a big one which
never gets finished. Sometimes the small step is just better overall ;-)

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

>
> Another thing.
> let's say we write a function that needs a number and a mapping:
>      void foo(const object<number,mapping> &);
>
> Then I have an object<number,sequence,mapping>.
> I would like to be able to call foo on it without any problems/casts. I.e.
> object<number,sequence,mapping> is an object<number,mapping>.
> More generally an object<list1> can pass as an object<list2> if list2 is a
> subset of list1.

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.

> Using gen_linear_hierarchy, the inheritance tree (and types in it) depend
> upon the order of types in the list.

That's why my sample code tried to normalize the order, constructing the
generators by iterating through all_capabilities.

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