I also like the last one best. I can always explicitly construct a bytes in my ambiguous situations.
-----Original Message----- From: cplusplus-sig-bounces+matthew.scouten=tradingtechnologies....@python.org [mailto:cplusplus-sig-bounces+matthew.scouten=tradingtechnologies....@python.org] On Behalf Of Haoyu Bai Sent: Wednesday, March 18, 2009 1:12 PM To: Development of Python/C++ integration Subject: Re: [C++-sig] Some thoughts on py3k support On Thu, Mar 19, 2009 at 1:52 AM, Stefan Seefeld <seef...@sympatico.ca> wrote: > Ralf W. Grosse-Kunstleve wrote: >> >> C++ has wchar_t and std::wstring. Could these be leveraged to avoid >> ambiguities? >> E.g. char, std::string are mapped to py3 byte objects, wchar_t and >> std::wstring >> to py3 str objects. >> > > I don't quite agree with that suggestion. First, wchar_t doesn't imply > Unicode (and char doesn't exclude it !). Second, I do want my existing > string functions (whether they use 'std::string' or 'char const *') to keep > operating on strings, not byte buffers. > I believe the only way to avoid ambiguities is by allowing / requesting > users to explicitly set a policy. > > Thanks, > Stefan > Yes of course we should allow users to set policy. So the problem is what the default behavior should be when there is no policy set by user explicitly. The candidates are: - raise an error - convert char* and std::string to/from Python bytes - convert char* and std::string to/from Python 3 unicode string. I personally like the last one because it would keep most of the existing code compatible. Thanks! -- Haoyu Bai _______________________________________________ Cplusplus-sig mailing list Cplusplus-sig@python.org http://mail.python.org/mailman/listinfo/cplusplus-sig _______________________________________________ Cplusplus-sig mailing list Cplusplus-sig@python.org http://mail.python.org/mailman/listinfo/cplusplus-sig
