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

[Niall Douglas]

On 19 Mar 2009 at 21:53, Haoyu Bai wrote:

> This naming style is a bit more clear but broken user's build scripts
> - not a big problem though. But when all the Python community evolved
> to py3k, and 2.x come into history, should we change the name back
> from libboost_python_py3.so to libboost_python.so?

Well in my own opinion every single library revision should have its 
own unique filename - makes it much harder to have unintentional 
problems due to ABI changes you see. It's not like anyone usually 
needs to type out any library filename by hand (or if they do, 
hitting Tab fixes it). And I personally don't mind breaking people's 
build scripts when it's for their own good! :)

> Would you mean for converting between char * and Python, we may use
> the encoding as same as Python interpreter's default encoding, which
> can be get by sys.getdefaultencoding() in Python? Or let user to
> choose default encoding for their extension module via Boost.Python
> API? I'd say either of these is very flexiable. Nice idea!

I didn't make myself clear with that post - thanks to a fourteen hour 
day yesterday during which I taught for two hours, created and gave a 
presentation on business process modelling and sat a two hour exam. 
But yes, I did mean that const char * is treated as whatever 
sys.getdefaultencoding() is unless specifically overridden by a 
template parameter specifier.

> Also I think to use the same default encoding as Python's
> sys.getdefaultencoding() it a bit better since it provides a
> unification in the whole Python environment. And it is configurable as
> Python's startup by sys.setdefaultencoding().

Indeed - I was trying to convey the notion that as Python changes we 
must change too.

> I'm felling the difference between char*, unsinged char* and the
> constant version and std::vector version of them would be a bit
> complicated and confusing. We may document it clearly, but things are
> still complicated. Any thoughts?

Well, the whole concept of BPL is that it is extensible via overload 
and partial specialisation. One might provide these as default out-of-
the-box but any client code is more than free to add their own type 
specialisations. The only actual concern is whether my proposed 
overloads are a bit too generic and might interfere with client code, 
but then that's why we have namespaces with Koenig lookup.

I should add that this philosophical difference is why I am not a 
Booster - I strongly feel that utility and power lies within flexible 
structure rather than simple abstraction. This is why I went off and 
wrote my own integrated metaprogramming library in TnFOX rather than 
use Boost's - I was more than happy to sacrifice support for non-
compliant C++ compilers in return for vastly cleaner and more 
powerful code. That said, as we are contributing towards BPL, I will 
be sticking my philosophical hat into a drawer for the duration :)

Cheers,
Niall