[C++-sig] Python API wrapping details

[David Abrahams]

----- Original Message -----
From: "Dave Hawkes" <daveh at cadlink.com>
Newsgroups: gmane.comp.python.c++
To: <c++-sig at python.org>
Sent: Thursday, June 20, 2002 9:44 AM
Subject: [C++-sig] Python API wrapping details


> I'm proposing the following  techniques for wrapping the python API for
BPL.
>
> Boost header files will be created from a python script. The script will
> contain a list of all the supported API functions and their attributes,
such
> as whether borrowed or new references are returned, error handling, etc.
All
> the API metadata will be defined in the python script. The python script
> will then use a set of rules to generate the API wrappers from this
> metadata.

That sounds slower than just doing it by hand overall. The API isn't that
big.

> This way if we find at some point we don't like the structure of the
> wrappers it is just a matter of adjusting the generator rules rather than
> re-editing all the headers.
>
> There are a few issues about the structure of the wrappers:
>
> 1) For functions that take non-PyObjects (ie int) as arguments should we
> still insist that the arg is wrapped in an object? Maybe there should be
> overloaded functions so that either type of arg is acceptable?

That's the approach I've been taking. It's not checked in yet, but I've
overloaded the xxxattr() function to accept char const* keys.

> 2) How should we deal with PyObect** args (ie PyString_InternInPlace)
should
> the argument type be object& or object*? I suspect its probably better to
> force the user to do an explicit &obj.

This is an artifact of a C implementation; we should think about what makes
sense for C++, and mirror Python's interface:

>>> intern
<built-in function intern>
>>> s = 'in-tern'
>>> id(s)
8814968
>>> z = intern(s)
>>> z
'in-tern'
>>> id(z)
8814968
>>> y = 'in-tern'
>>> id(y)
8805080
>>> intern(y)
'in-tern'
>>> id(intern(y))
8814968
>>> id(y)
8805080

> 3) Should all functions always return an object (unless they are void)?

Not neccessarily

> There may be efficiency concerns if we keep wrapping int returns all the
> time.

It depends how things are used. What functions did you have in mind?

> We could also provide versions of the functions that do either (though
> we can't overload on return type). Some return types may not even be
> appropriate to return as an object (ie FILE*).

try:

    >>> help(file)

HTH,
Dave