[C++-sig] Re: 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 11:16 AM
Subject: [C++-sig] Re: Python API wrapping details


>
> "David Abrahams" <david.abrahams at rcn.com> wrote in message
> news:0f8401c21867$9d4d9280$6601a8c0 at boostconsulting.com...
> > > 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.
> >
>
> I think it will be less error prone this way, particularly if we find
that
> we want a large number of overloads of the same function.
>
> > > 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.
> >
>
> OK
>
> > > 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:
> >
>
> 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.

> Would you consider 'growing' the object declaration to include
> the API?

No, that would be bloaty (and unneccessary).

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

Note for example that:

    x < y => bool

> > It depends how things are used. What functions did you have in mind?
> >
>
> Functions like PyObject_HasAttrString, but then, as above, this is so
> 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.

> Yes I know there is a PyFileObject. but the intent of some of the file
api
> is to allow the user access to the underlying FILE*, which you won't get
if
> the result is wrapped in object as a python file.

OK, you're right about this one.

-Dave