boost::python, returning new PyObject references

[Arnaldur Gylfason]

Hi Dave,

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
altogether

    * There are no tests for the generic sequence and mapping. Is that
      intentional?

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
that's
      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
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.
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
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 (?).


    * The lack of comments in the code makes it hard to understand what
you're
      aiming at.

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
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.
I think we should think about this part and decide between public/private
inheritance.

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
item access.
What do you think about that?

Cheers

Arnaldur