[C++-sig] Some thoughts on py3k support

Haoyu Bai divinekid at gmail.com
Tue Mar 17 19:07:56 CET 2009


Hi,

Here is some thoughts on GSoC Boost.Python py3k support project.

First thing come into my mind is the build system. For Python 3, we
would have a separate build target, eg. having libboost_python.so
built for Python 2.x and libboost_python3.so for Python 3. This would
match the current situation that most Linux distro packaged Python 3
in a way that lives together with Python 2.x. There's two build system
for Boost now - cmake and bjam. Personally I want to start with cmake,
and finally both of the two will up to date for Python 3.

I have read some piece of Boost.Python code in these, it is
understandable for me. And I'd say the usage of template
metaprogramming is really smart! Thanks to the high level abstraction,
there would be just a little code interfaced to Python C-API directly.
So there would not be so much works.

However there are something we need to take care of. One of them is,
in Python 3, string is unicode (and the old string class is called
bytes in Python 3). So if we have a C function

char const* hello(); // returns a "Hello"

According to the current behavior of Boost.Python converters, the
wrapped function in Python 3 will return a b"Hello" (which is a bytes
object but not a string). So code like this will broken:

if "Hello" == hello(): ...

Because string object "Hello" is not equal to bytes object b"Hello"
returned by hello(). We may change the behavior of converter to return
a unicode string in Python 3, that would keep most of existing code
compatible. Anyway there will be code really need a single byte string
returned, a new converter can be explicitly specified for this.

There are more issues similar to this. I'll figure out more and write
a detailed proposal as soon as possible.


Best regards,

Haoyu Bai


More information about the Cplusplus-sig mailing list