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 _______________________________________________ Cplusplus-sig mailing list Cplusplus-sig@python.org http://mail.python.org/mailman/listinfo/cplusplus-sig
