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

[Matthew Scouten (TT)]

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.com at python.org [mailto:cplusplus-sig-bounces+matthew.scouten=tradingtechnologies.com at 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 <seefeld at 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 at python.org
http://mail.python.org/mailman/listinfo/cplusplus-sig