[C++-sig] Re: Re: Python API wrapping details

[Dave Hawkes]

"David Abrahams" <david.abrahams at rcn.com> wrote in message
news:126b01c21921$641b2170$6601a8c0 at boostconsulting.com...

> > with string there is no capitalize 'C' API method.
>
> likewise s.attr("capitalize")()
>
> However, I do want to have a str type derived from object which has all
the
> known string methods as member functions directly:
>
>     s.capitalize()
>
>
> > And then again the
> > builtin functions hex and oct are not directly exposed.
>
> I think we could look them up on demand and expose them, but aren't they
> somewhat trivial to write directly?
>

> > The python 'C' API appears to be designed to facilitate interfacing with
> > python rather than exposing its functionality
>
> I don't get what the difference is, yet.


I suppose it a matter of intended purpose, for example PyObject_Hash is
clearly provided to expose the internal python function hash and both are
likely to be used in similar ways in both C/C++ and Python. So here the API
is exposing hash as a piece of python functionality that would be awkward
replicate precisely outside of python.

However the API function PyFile_AsFile has no real built-in counterpart
(fileno is the closest) because it is provided purely to allow the user to
'interface' with the python file object.

The builtin hex function however is fairly trivial to implement outside of
python and is not required at all to interface with python and is therefore
not exposed at all.

So I'm thinking that some functionality should be exposed through the use of
the API where there is a direct duality with the corresponding python
functions Other functions where the duality is not so clear should just be
exposed by calling the internal python function directly.

>
> > so I'm beginning to wonder
> > what we should be doing here. For example should the builtin python
> > functions that have no 'C' API be exposed through the likes of
> > PyObject_CallFunctionObjArgs?
>
> No, they should be exposed through call<>(), so we get the C++ -> Python
> type conversions.
>

I was thinking of the cases where we want all args to be object and the
result to be an object, but, yes, it probably makes sense to use the
call<>() mechanism for everything anyway.

> > Perhaps we should concentrate on exposing those functions that are
> required
> > to carry out the interface tasks between python and c++.
>
> Like which ones?
>

see above.

> > I was thinking ahead to try and keep things consistant.
>
> I appreciate the attention to consistency. I don't see how using member
> functions improves consistency, though.
>

I meant thinking ahead to see what we do about the API functions that don't
correspond directly to builtins. The member function thought was just one of
those things that struck me when I looked at the API list and saw PyObject*
as the first argument to most calls. But as you say it would then not
function equivalently to python.

Dave Hawkes