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

[David Abrahams]

From: "Dave Hawkes" <daveh at cadlink.com>


>
> "David Abrahams" <david.abrahams at rcn.com> wrote in message
> news:0fc101c2186e$ed449840$6601a8c0 at boostconsulting.com...
> > > Using that logic would mean that the vast majority of these functions
> > should
> > > really be members of object as their first parameter is invariably
> > > PyObject*?
> >
> > No, they're not methods in Python; they should be free functions in
> > Boost.Python.
> >
>
> I was thinking about the built-in type member functions such as the file
> functions. Also file objects appear to have a bit of a dichotamy between
the
> python API and the 'C' API, for example there is no 'C' seek function.

Of course, there's always f.attr("seek")(offset)

> Even
> 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.

> 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.

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

Like which ones?

> OK, I'm rambling here, basically I'm saying there's two separate elements
to
> this. Exposing the pure python functionality and exposing the python
> interface functionality and I thinkg they mah have slightly different
> requirements.

Maybe; I'd need to hear more to form an opinion.

> > > commonly used maybe it should be a member anyway.
> >
> > a. That wouldn't change anything w.r.t. the return type
> > b. No, we want hasattr(x, "foo"), just like in Python
> >
> > Read my original post which suggested starting by replicating the
Python
> > built-ins.
> >
>
> 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.

-Dave