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

[Dave Hawkes]

"David Abrahams" <david.abrahams at rcn.com> wrote in message
news:0acc01c217ce$0702c8c0$6601a8c0 at boostconsulting.com...
> After a little testing I discovered that the object class didn't allow
> certain kinds of expressions, e.g.
>
> object f(object list_of_lists)
> {
>     list_of_lists[0][1] = 5;
> }
>
> Basically the proxy being returned by item (operator[]) and attribute
> (attr()) access functions was not defined to support all of the same
> operations as the object class itself. Getting this to work was "fun" ;-),

I can see that..

> especially since it uncovered code generation bugs in MSVC6 and GCC
2.95.x.
>

There's a surprise -;)

> 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

> 2. Move code generated by the use of object and its proxies into the
shared
> library. I expect that the natural use of object instances generates a
fair
> amount of code in the user's extension module which could be shared,
> reducing both compilation times and the size of extension modules. This
job
> is more ambitious and requires some understanding of the differences in
> template instantiation and shared libs among different
platforms/compilers.
>

I noticed object.ptr().get() is really needed quite a bit and you created a
wrapper for it.
Maybe there should be an object member function called ptr_get()?

Dave Hawkes