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

[David Abrahams]

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


> I see what you mean from the sample. I didn't consider the possibility of
2
> co-operating modules, one boost, one not, though not sure how often this
> would occur in practice.

Often enough. Consider popular packages like NumPy...

> > > and
> > > result in an unnecessary data member for the default case.
> >
> > What data member?
> >
>
> The T* m_ptr which would not be required for the default object<>.

Oh, I had misunderstood what you were going to point at. When you said
"like handle<>", I assumed you meant that it would be a smart pointer to a
Python object (e.g. PyTypeObject).

> > Yes, I was trolling for name suggestions for this function. I don't
like
> > get() because that traditionally acccesses the same thing as
operator->(),
> > and the derived lvalue_ptr-thing will cover the get() function with its
> > own, which accesses something else.
> >
>
> Maybe something like get_native(), native_ptr() or just native().

What about raw()? Hopefully people won't be doing this much.

> It would also be useful to be able to extract the handle<> directly
somehow
> (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'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.

> > I'm not sure it's all that useful. Perhaps the derivation from object
> isn't
> > such a hot plan after all, and I should do the small amount of extra
> > implementation work implied by making it a non-derived class.
> >
>
> Maybe, as there isn't to much of the object functionality that's really
> useful for a class instance besides attributes.

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.

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

-Dave