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

[Dave Hawkes]

"David Abrahams" <david.abrahams at rcn.com> wrote in message
news:01ef01c21321$6c19bdb0$6601a8c0 at boostconsulting.com...
> From: "Dave Hawkes" <daveh at cadlink.com>
> >
> > 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.
>

OK, maybe it's not worth worrying about the small number of times a NULL
PyObject* is really needed. When the python function wrapping is completed
then we'll just use the no-argument versions.

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

I was thinking of just letting handle use the traits rather than call use
them as well, which would possibly add unnecessary complexity.

>
> > if
> > it can't then we will have to rely on run-time exceptions.
>
> How would you do it at run-time?

I wasn't sure if we could make use of  PyType_IsSubtype or
PyObject_IsSubclass in some cases.

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

Will handle<> and object be able to be used interchangeably then?

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

Yes, it would be easier to add this later if practical problems arise,
rather than take it away.

Dave Hawkes