boost::python, returning new PyObject references

[David Abrahams]

On Saturday, December 29, 2001, at 12:05 PM, Arnaldur Gylfason wrote:

Hi Arnaldur,

> I'ts not just testing if it compiles though. By printing data and 
> returning
> data, I can verify things visually by loading the module in python and
> calling the functions there.

OK.

>
>     * There are no tests for the generic sequence and mapping. Is that
>       intentional?
>
> It's mostly tested through the proxies for the moment.

I don't understand what you mean by that.

> I'll stress that this is mostly for seeing if the design works. Unit 
> tests
> have to be added.

Understood.

>     * It seems to me that "callback" is an insufficiently descriptive 
> name.
>       Maybe "set_function" or "assignment_action" would be better... if
> that's
>       what it does. What is the purpose of the callback?
>
> It is used if the ref has a Null PyObject*.

And when does that occur?

> It is true that it is just used
> for mapping.
> (Should be used for dictionary also). The reason for it in those cases 
> is
> detecting illegal key access
> but allowing setting new key-value pair.


Normally a proxy would only do the access on demand. I can't think of 
any reason to hold a reference to an object other than the underlying 
sequence or mapping in the proxy. Oh, well I guess in the mapping case 
the proxy should hold a reference to the key object and the underlying 
sequence.


> You're right that it is probably better to override the get() and 
> reference
> () methods for mapping
>  (dictionary later) instead of putting it in object_base.

Did I suggest that? I'm not sure what you're referring to.

>     * Why does sequence::append call PyListe_Append? That doesn't seem 
> like
>       the generic interface for sequence we had in mind.
>
> That is a mistake on my part.

OK.

>     * Why are there separate sequence and mapping proxies if they both
> carry a
>       callback to do the work? It looks to me like a single proxy class
> would be
>       more appropriate.
>
> The mapping proxy sets a callback to grab illegal key access.
> Maybe they can be combined though (?).

It seems to me that a less-effortful proxy design using callbacks would 
take a pair of function objects, get() and set(), which are responsible 
for extracting an object from or inserting the object into the container 
at the appropriate index or key. That design could be reused for any 
mutable python container that might come along.

>     * What is the point of having objects.hpp and objects_b.hpp? Are 
> there
>       advantages/disadvantages to one or the other?
>
> By using callbacks we can save us some proxy classes.
> But the callback version is maybe harder to understand.

I guess I still don't have a good overall picture of what you're doing.

>     * Shouldn't sequence inherit privately from object? I don't think 
> that
> a
>       sequence in general has a __call__ operation. What we discussed 
> was
>       a fully-generic class "object" which supplies the full Python 
> object
>       interface, with privately derived classes for more-restrictive
> interfaces,
>       using using-declarations to expose public access to the 
> appropriate
>       functions.
>
> The object interface is general but has some methods that might not be
> implemented (i.e. __call__ (PyObject_CallObject)).
> That goes for all objects. The user has to know if the object supports 
> it
> or not.

What's the point of having different C++ types, then? You could just use 
the generic object for everything. I suppose there would be a very minor 
speed improvement if you know that an object is in fact a list rather 
than some generic sequence, but I don't think too many people are 
concerned about the speed of code operating at the C++/Python boundary.

> I think we should think about this part and decide between 
> public/private
> inheritance.

I think these are fundamental questions, and they have less to do with 
inheritance per-se than the intended meaning of the type system.

> I'll clean things up and send you again (with the number interface).
> Are you happy with the virtual inheritance?

Sure, why not?

> What do you think about the use of callbacks?

There's nothing wrong with it in principle, but I'm not sure you've 
taken the best advantage of them.

> I think we can use the iterator_proxy for list (the iterator support) 
> for
> item access.
> What do you think about that?

I think I'll need you to clarify what you're doing a bit more before I 
can form a useful answer.

Thanks,
Dave