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

[David Abrahams]

From: "Dave Hawkes" <daveh at cadlink.com>
>
> "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.

No, I don't think so. That would construct an argument tuple containing a
NULL object entry, and that's never legitimate.

> >
> >     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:

Yes, that's what I'm asking below.

>     call<void>(my_function, handle<>(PyObject_GetAttrString(x, y)))
>
> that way we can also do:
>
>     call<void>(my_function, handle<>(borrow(PyImport_AddModule(name))))

Yeah; I had that thought myself. The only problem here is that making
variety "B" pointers (at least the ones we don't already know about) cause
a compiler error depends on the user specializing some traits, with the
only purpose being to make certain code fail to compile. Who's going to do
that?

OTOH, we already know about most of the variety B pointers.

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

How do you think the conversion above works? There's a traits class called
base_type_traits<>, specialized for PyTypeObject.

> if
> it can't then we will have to rely on run-time exceptions.

How would you do it at run-time?

> > 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 ?

All object instances will point to a real object; that's part of the
design, and I think not open to negotiation. You can always make a null
handle<> if you need one for something. I would need to see some
compelling, specific examples to be convinced otherwise. Remember, the
Python "C" API is always available if something really unusual is required.

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

That's a good point. Much better to try to live without a dangerous
facility first.

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

Very nice; thanks for the clear thinking!

-Dave