[C++-sig] Re: Boost.Python v2: reference-counting and user-friendly conversions

[Dave Hawkes]

"David Abrahams" <david.abrahams at rcn.com> wrote in message
news:013e01c212f9$da854940$6601a8c0 at boostconsulting.com...
>
> Questions:
>
> 1. How should we handle raw Python object arguments to
> call<>/call_method<>?
>     a. is NULL->None conversion a good idea for these particular pointers?
>        I still think it makes sense for most pointers, but maybe not
these.
>        see
>
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/boost/boost/libs/
> python/doc/v2/callbacks.html
>        for a review of semantics

As this probably acceptable for the fast majority of cases then yes, but
provide the ability to pass a true NULL by passing something like a
null_object class if the user really does need to do this.

>
>     b. is there any reason to think that stealing semantics should be
>        introduced, so that:
>
>             call<void>(my_function, PyObject_GetAttrString(x, y))
>
>        would work correctly? Remember that we will be providing wrappers
> for
>        the Python API functions. Also remember that my_function is
> currently
>        a PyObject* which is /not/ stolen.
>

Which then begs the question should a raw PyObject be allowed as an argument
at all? Is it too much too insist that the user does this:

    call<void>(my_function, handle<>(PyObject_GetAttrString(x, y)))

that way we can also do:

    call<void>(my_function, handle<>(borrow(PyImport_AddModule(name))))


>     c. Is it important to be able to accept variety A and B of
>        raw Python object pointer as arguments here? Remember that we will
>        have object and handle<> whose refcount semantics are unambiguous
>

see above.

>     d. Is it reasonable to require a traits specialization or other action
>        from the user to explicitly denote variety B? We can neither
> generate
>        a compile-time error nor special handling if we can't detect them.
>

I would prefer just to rely on the type conversion provided by handle<> etc.

    PyTypeObject* p
    handle<>(type_handle(p)).get()

If the handle type conversion can be verified at compile time then fine, if
it can't then we will have to rely on run-time exceptions.

> 2. How should we handle raw Python object arguments to the object()
> constructor?
>     a. is NULL->None conversion a good idea for these particular pointers?
>

Yes, if there is some explicit way to create a NULL if we really need one,
maybe it should be a derived class, null_object ?

>     b. is there any reason to think that stealing semantics should not be
>        used?
>

We will then have to live with this assumption once people are using V2 and
it will be difficult to go back. I'd rather disallow raw PyObjects.

>     c. Is it important to be able to accept variety A and B of
>        raw Python object pointer as arguments here? Remember that we will
>        have object and handle<> whose refcount semantics are unambiguous
>

No, get rid of the raw PyObjects, If we have an effective solution in handle
lets concentrate reference counting, type converting etc. in one place.

Dave Hawkes