[C++-sig] Boost.Python code generator

[Nicodemus]

Ralf W. Grosse-Kunstleve wrote:

>Do you have a plan for dealing with "Python only" member functions? How would
>you deal with, for example, a __getitem__ that does range checking and raises
>the proper Python exception if necessary (assume there is no range-checking
>member function in C++). 
>
Actually, I have plans to support it. My basic idea was that the user 
should simply state:

class A
    operator [] (key int, type float, range 0-size())
    def size


And it would generate this wrapper code:


float A__getitem__(const A& a, int key)
{
    if ( key >= 0 && key < a.size() )
    {
        return a[key];
    }
    else {
        // throw an IndexError
    }
};

void A__setitem__(A& a, int key, float value)
{
    if ( key >= 0 && key < a.size() )
    {
        a[key] = value;
    }
    else {
        // throw an IndexError
    }   
}


But I don't know if this will work for most cases... I have to study it 
more. Also, there are other cases to consider, like pickle support, as 
you mentioned (mind you I know nothing about Boost.Python & Pickle ;).
Notice thought, that the user can always do something like this:


file A.pkle.h
-------------

#include "A.h"

boost::python::tuple
getinitargs(any const& o)
{
    // code for building the tuple here
}

file A.pyi
-------------
include A.pkle.h

class A
    def __getinitargs__(freefunc getinitargs)
    ...

Clumsy, but would work. 8)

>An ad hoc idea is to have some kind of "inline" or "verbatim" statement, e.g.:
>
><verbatim>
>  boost::python::tuple
>  getinitargs(any const& o)
>  {
>    // code here for building the tuple
>  }
></verbatim>
>
>  class any
>    def foo # any plain member function
>    def __getinitargs__=free(getinitargs)
>  
>

I would not like to go that path... I had considered this, but I prefer 
that the user doesn't have to write code in the interface file. One of 
the goals of the interface file is to make it simple as possible.
But I have other cases to consider, and if those cases break the 
interface (like needing too many information to do its work), I might 
have to include embeded code.

>This leads to the idea of turning the "inline" approach upside-down:
>expect C++ code with embedded pyste fragments. Can you see this working for
>your runtime-polymorphic types?
>

You mean include pyste fragments in the header files? The objective of 
the interface file is that it is not intrusive in the library that it is 
trying to export, like boost.

About the embeded code, this is something that I considered, but I will 
follow this path only if the interface gets too clumsy trying to support 
things natively, like for example the [] operator. I will now export 
some classes to the interface files, analysing the various needs... if 
those needs start to get too complex for the simple interface, I might 
have to consider embeded code.

>
>Ralf
>
Thanks for the comments Ralf,
Nicodemus.