[C++-sig] current spelling of from_python<>?

[David Abrahams]

----- Original Message -----
From: "Ralf W. Grosse-Kunstleve" <rwgk at yahoo.com>
To: <c++-sig at python.org>
Sent: Tuesday, June 11, 2002 5:12 PM
Subject: Re: [C++-sig] current spelling of from_python<>?


> --- David Abrahams <david.abrahams at rcn.com> wrote:
> > From: "Ralf W. Grosse-Kunstleve" <rwgk at yahoo.com>
> >
> >
> > > Until about a week ago the code below worked as a placeholder
> > > for a user-level from_python<> converter:
> > >
> > >   template <typename U>
> > >   struct extractor
> > >   {
> > >     static
> > >     U
> > >     get(PyObject* obj)
> > >     {
> > >       Py_INCREF(obj);
> > >       return converter::callback_from_python<U>()(obj);
> > >     }
> > >   };
> > >
> > > converter::callback_from_python<> is defined in the obsolete file
> > > converter/callback.hpp. What should I be using instead?
> >
> >     converter::return_from_python<> in converter/return_from_python.hpp
>
> Using return_from_python<>, extractor<T> works fine. Thanks!
> Is it expected that extractor<T const&> does not work for
> converting the elements of a Python tuple of Python float or int?

return_from_python<> converts Python function return values to C++

Rhetorical question: does the Python int contain an int lvalue? Does the
Python float contain a float lvalue?
Answer: no, a Python int contains a C++ long; a python float contains a C++
double.
So what would the int const& refer to?

Question: OK, what about long const&?
Answer: Python doesn't actually expose the contained long lvalue as part of
the documented interface, so we can't touch it.

[short answer: yes]

> I also need this convertible() test:
>
>     static void* convertible(PyObject* obj)
>     {
>       using namespace boost::python;
>       tuple t = list_or_tuple_as_tuple(obj);
>       if (!ContainerAdaptor::check_size(
>         type<ContainerType>(), t.size())) return 0;
>       for(std::size_t i=0;i<t.size();i++) {
>         arg_from_python<container_element_type const&>
from_py(t[i].get());
>         if (!from_py.convertible()) return 0;
>       }
>       return obj;
>     }
>
> Observations:
>
> The code as shown works with Linux/gcc304, but VC6 reports
> "indirect_traits.hpp(308) : error C2057: expected constant expression."
> arg_from_python<container_element_type> also works with Linux/gcc304, but
VC6
> reports "fatal error C1001: INTERNAL COMPILER ERROR."
> Should/could I use a different approach for testing convertibility that
VC6
> might not choke on?

Try breaking up the definition of value into little steps so that the
expression is simpler.

G'luck,
Dave