[C++-sig] Re: Boost.Python problems

[David Abrahams]

"Ben Hutchings" <ben.hutchings at businesswebsoftware.com> writes:

> David,
>
> I have recently tried to use Boost.Python as released in Boost
> 1.29.0.

Hi Ben,

1. The current release is 1.30.0.

2. Please post Boost.Python related stuff to the python C++-sig:
   http://www.python.org/sigs/c++-sig/

> It's obviously very useful, but it still has a few bugs and limitations.
> It turns out that I won't need to use Boost.Python now, but I thought I
> should let you know about these problems.
>
> 1. <boost/python/object_core.hpp> doesn't include the class definition
>    for policies.  The proxies it defines can't be used without these
>    definitions.  This limitation is mentioned in the header but not
>    documented elsewhere.

You're not supposed to include object_core yourself; it's an
implementation detail.  The documentation doesn't mention
object_core.hpp, only object.hpp.

> 2. <boost/python/detail/exception_translator.hpp> doesn't include
>    <boost/python/detail/config.hpp>

Why is that a problem?  It doesn't seem to need it.

Any headers in boost/python/detail are also implementation details,
and not for user consumption.

> 3. The test programs are run without quotes around the path to the
>    python interpreter.  On Windows it is not uncommon to have spaces in
>    a path name, in which case the tests fail to run at all.

Are you saying that bjam fails to quote the path, or something else?

> 4. There are no converters for std::wstring or wchar_t.

Good point.  Care to contribute some?

> 5. boost::python::converter::registry doesn't seem to be documented.

Right.

>    As far as I can see, this is essential for installing new
>    conversions for rvalues that aren't implicit in C++.  I may just
>    have missed something though.  (The specific things I used this for
>    were conversions from unicode to std::string and from str to
>    std::wstring.)

No, you're right.  I was never satisfied enough with the interface to
consider it worth publishing.  We're going to rework some of that
stuff for the next release and it will be documented then.

> I have attached a patch that deals with item 4, 

Wonderful!

> though it isn't good enough as it is.  The STATIC_ASSERTs need to be
> taken out and all the new code should be conditional on Python's
> HAVE_USABLE_WCHAR_T macro.  I don't know what to do about
> environments where wchar_t is typedef'd.

Thanks; we'll look into it.

> I hope this is useful to you.  If not, sorry for wasting your time.

Thanks very much for your input.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com