boost::python, returning new PyObject references
arnaldur at decode.is
Sat Dec 29 18:05:40 CET 2001
Some answers/comments to your remarks:
* (Trivial) please use spaces instead of tabs - this applies to
all of your files.
Sorry. I use textpad and supposedly have all tabs changed to spaces when
saved (must check that now!).
* It doesn't test anything other than that certain constructs
compile. There should be assertions or other semantic checks
that verify the behavior.
That's right there isn't any real testing there. I mean to add unit tests
when we've settled on the design.
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.
* What is the purpose of the large commented-out section at the top?
It has nothing to do with what we're adding now so it's best to delete it
* There are no tests for the generic sequence and mapping. Is that
It's mostly tested through the proxies for the moment.
I'll stress that this is mostly for seeing if the design works. Unit tests
have to be added.
* It seems to me that "callback" is an insufficiently descriptive name.
Maybe "set_function" or "assignment_action" would be better... if
what it does. What is the purpose of the callback?
It is used if the ref has a Null PyObject*. It is true that it is just used
(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.
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.
* 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.
* Why are there separate sequence and mapping proxies if they both
callback to do the work? It looks to me like a single proxy class
The mapping proxy sets a callback to grab illegal key access.
Maybe they can be combined though (?).
* The lack of comments in the code makes it hard to understand what
I'll add some
* Some of your lines are so long that they're difficult to understand,
Guilty there. I've never set up any working rule regarding that. I'll try
to change that.
* Lots of commented-out code in this file obscures your intention also.
Sorry, remains of some experimentations. It'sstill there because I haven't
decided the final design yet.
* 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.
* Shouldn't sequence inherit privately from object? I don't think that
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
using using-declarations to expose public access to the appropriate
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
I think we should think about this part and decide between public/private
I'll clean things up and send you again (with the number interface).
Are you happy with the virtual inheritance?
What do you think about the use of callbacks?
I think we can use the iterator_proxy for list (the iterator support) for
What do you think about that?
More information about the Cplusplus-sig