[C++-sig] Re: Re: Boost.Python v2: object facilities updated

[David Abrahams]

----- Original Message -----
From: "Dave Hawkes" <daveh at cadlink.com>
Newsgroups: gmane.comp.python.c++
To: <c++-sig at python.org>
Sent: Wednesday, June 19, 2002 8:31 PM
Subject: [C++-sig] Re: Re: Boost.Python v2: object facilities updated


>
> "David Abrahams" <david.abrahams at rcn.com> wrote in message
> news:0b8601c217e9$c4ee0ff0$6601a8c0 at boostconsulting.com...
> >
> > From: "Dave Hawkes" <daveh at cadlink.com>
> >
> > > > Next up: slicing, then list, tuple, dict, type, etc...
> > > >
> > > > Two jobs I could use help with:
> > > >
> > > > 1. Examine places in the public interface to the rest of the
project
> > for
> > > > uses of PyObject* or handle<T> which should really be using object.
> > Make a
> > > > proposal for appropriate interface changes.
> > > >
> > >
> > > I'll tidy up the code for global module/sub-module/nested classes
> support
> > to
> > > use this where appropriate
> >
> > Thanks. I'm really looking forward to integrating this stuff -- when I
> find
> > a few minutes ;-/.
> >
>
> OK
>
> > > I noticed object.ptr().get() is really needed quite a bit and you
> created
> > a
> > > wrapper for it.
> >
> > I assume you're seeing converter::get_managed_object() - that's not
really
> > a wrapper for ptr().get(); it just happens to do that when passed an
> > object. Seriously; it has a different purpose.
> >
>
> I guessed it was intended to be something symantically different from the
> converter context, but the end result was the same for object.
>
> > > Maybe there should be an object member function called ptr_get()?
> >
> > Didn't we just discuss this, with the conclusion that we shouldn't
provide
> > direct access to the PyObject*?
> > Or are you just talking about implementation details?
> >
>
> Yes, we did, but using the new code revealed that it was needed more than
I
> anticipated, but that will probably change when the API wrappers are
> complete. If that's not far away then it's probably not worth worrying
> about.

In theory it's not, but I could really use some help with that stuff. Do
you think you might take on the job of fleshing out the missing pieces?
It's fairly mechanical, mostly, but requires some attention. My idea was to
follow the Python/C API documentation and make files like
object_protocol.hpp which mirror pages like
http://www.python.org/dev/doc/devel/api/object.html. Of course, many
functions are covered by the operators already defined, so we don't need
separate functions for those. The idea is just to cover the built-in
functions (http://www.python.org/dev/doc/devel/lib/built-in-funcs.html) and
any 'C' API functions which aren't otherwise handled.

-Dave