[C++-sig] Re: Re: Re: Boost.Python v2: beginning of generalized object support

[Dave Hawkes]

"David Abrahams" <david.abrahams at rcn.com> wrote in message
news:030801c21663$3532a4c0$6601a8c0 at boostconsulting.com...
> > (return the private handle<>  instance).
>
> is that better than handle<>(borrowed(p.raw()))?
> Actually, I prefer to make the raw pointer less-accessible, so:
>
>     p.handle() -> handle<>
>     p.handle().get() -> PyObject*
>
> Which solves one naming problem, anyway.
>

I prefer that too, get the managed handle and if the pointer is really
needed, then go from there.

> > > > I'm not that keen on lvalue_ptr as it is not particularly explicit.
> > >
> > > Me neither.
> > >
> >
> > If verbosity is not important then there is class_obj_ptr.
>
> But accuracy is important. You could write:
>
>     lvalue_ptr<char const> x(string("x"))
>
> which would get you a smart pointer to the 'x' character managed by a
> Python string object. I realize this one is esoteric, but consider Python
> buffer objects, wrapped boost::array<double>, etc...
>
> The point being that it doesn't have to refer to a class.
>

So in effect it's managing any object that contains a representation that
can be pointed at and can be directly manipulated. In that case almost every
python object could be represented somehow with some form of specialization.
So a lvalue_ptr<PyIntObject> could contain a pointer to its integral long.
Did I see some earlier thread about accessing int, etc directly? Maybe this
is going a bit too far...

>
> I was thinking that if you have direct access to the C++ lvalue being
> referred to, do you really want a fancy interface to the Python wrapper? I
> mean:
>
>     lvalue_ptr<base> b(some_object);
>     object elt = b[1];
>     b->cplus_plus_method();
>     b->member = 2;
>     b.attr("member") = 2; // synonym
>
> Is that too wierd? I kinda like it, I hate to admit.
>

I was also thinking of adding attributes that are not members in the first
place, but then, of course, they would not be accessible as c++ members
afterwards either.

> > > > , but object_ptr could be misconstrued. I'm not much
> > > > help here, what else could (or should) this ptr contain besides an
> > > extension
> > > > class instance, maybe that will give some more hints for a name.
> > >
> > > It will hold a Python object which can be converted to (and thus
> contains)
> > > an lvalue of type T. That's why I chose "lvalue_ptr".
> > >
> >
> > OK
>
> Does that mean you actually buy lvalue_ptr? I wish we could find something
> less tweaky...
> Maybe object_ptr<T> is best.
>

If it can generalised to encompass many builtin python types then that could
well be more appropriate.
I'm running out of further ideas here.

Dave Hawkes