on Wed Apr 08 2009, David Abrahams wrote:
> I think you raised a number of irrelevant issues whose relevance I can't
> see, but I agree with the substance of your argument.
And I raised a number of redundant issues that were redundant with one
another... sorry, I didn't mean to hammer that poin
on Thu Mar 19 2009, "Niall Douglas" wrote:
> On 19 Mar 2009 at 21:53, Haoyu Bai wrote:
>
>> 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
on Wed Mar 18 2009, "Niall Douglas" wrote:
> On 18 Mar 2009 at 2:07, Haoyu Bai wrote:
>
>> 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:
>>
>>
On Donnerstag 19 März 2009, Matthew Scouten (TT) wrote:
> Ok, Fine. But I want the ability to specify an encoding ONCE and have
> use that unless I change it or override a specific conversion.
I would want such a thing, too. (Assuming that all 8-bit strings *do* use the
same encoding, which will
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_p
On 20 Mar 2009 at 0:20, Haoyu Bai wrote:
> Yes unicode string can't faster than raw string. However one can use
> the bytes object while regarding to performance.
I took from reading the py3k docs that strings are now always held
internally as utf-8?
On that assumption I proposed the treating o
:
cplusplus-sig-bounces+matthew.scouten=tradingtechnologies@python.org
[mailto:cplusplus-sig-bounces+matthew.scouten=tradingtechnologies@py
thon.org] On Behalf Of Hans Meine
Sent: Thursday, March 19, 2009 11:36 AM
To: cplusplus-sig@python.org
Subject: Re: [C++-sig] Some thoughts on py3k support
On Thursday 19 March 2009 09:02:35 Haoyu Bai wrote:
> By default we would use PyUnicode_AsUTF8String(), and encoding could
> be explicitly specified by a converter policy. That may keep most of
> your code compatible.
Please do *not* hard-code UTF-8. At least, if you need to guess a default,
use
On Fri, Mar 20, 2009 at 12:07 AM, Ralf W. Grosse-Kunstleve
wrote:
>
>> Of course the default converter policy we planed is not to convert to
>
>> raw data buffer from unicode object via PyUnicode_AS_DATA(). The C-API
>> such as PyUnicode_AsUTF8String() and PyUnicode_AsEncodedString() will
>> be us
> Of course the default converter policy we planed is not to convert to
> raw data buffer from unicode object via PyUnicode_AS_DATA(). The C-API
> such as PyUnicode_AsUTF8String() and PyUnicode_AsEncodedString() will
> be used to convert unicode to bytes and then convert to char* and
> passed to
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?
Can we postpone
On Thu, Mar 19, 2009 at 8:05 AM, Niall Douglas
wrote:
> On 18 Mar 2009 at 2:07, Haoyu Bai wrote:
>
> I'd prefer a slightly different naming convention for the eventual
> case when Boost.Python itself bumps a version. How about this:
>
> libboost_python_py2.so
> libboost_python_py3.so
>
> I'd also
On Thu, Mar 19, 2009 at 6:40 AM, Ralf W. Grosse-Kunstleve
wrote:
>
> I tried the code below with Python 2.x. For a given str or unicode object, it
> copies the
> bytes in memory (char*) to a list of 1-character strings. I'm getting
>
> "hello" = ['h', 'e', 'l', 'l', 'o']
> u"hello" = ['h', '\x0
On 18 Mar 2009 at 2:07, Haoyu Bai wrote:
> 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 d
;, '\x00', '\x00', '\x00', 'e', '\x00', '\x00', '\x00', 'l',
'\x00', '\x00', '\x00', 'l', '\x00', '\x00', '\x00', 'o', '\x00', '
Haoyu Bai wrote:
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/
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 wrote:
> Ralf W. Grosse-Kunstleve wrote:
>>
>> C++ has wchar_t and std::wstring.
On Thu, Mar 19, 2009 at 1:52 AM, Stefan Seefeld 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 d
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
ginal Message
From: Haoyu Bai
To: Development of Python/C++ integration
Sent: Wednesday, March 18, 2009 7:53:25 AM
Subject: Re: [C++-sig] Some thoughts on py3k support
On Wed, Mar 18, 2009 at 7:25 AM, Rene Rivera wrote:
> Matthew Scouten (TT) wrote:
>>
>> I can work with whate
On Tuesday 17 March 2009 21:23:03 Matthew Scouten (TT) wrote:
> I can work with whatever you come up with, but it might convenient if a
> char* or char[] was treated as a bytes object and a std::string was
> treated as a string. Thoughts?
I would say one cannot see from the type (i.e. std::string,
On Wed, Mar 18, 2009 at 7:25 AM, Rene Rivera wrote:
> Matthew Scouten (TT) wrote:
>>
>> I can work with whatever you come up with, but it might convenient if a
>> char* or char[] was treated as a bytes object and a std::string was
>> treated as a string. Thoughts?
>
> A char* can never be fully tr
Matthew Scouten (TT) wrote:
I can work with whatever you come up with, but it might convenient if a
char* or char[] was treated as a bytes object and a std::string was
treated as a string. Thoughts?
A char* can never be fully treated as a bytes object. You must mean a
char* plus a size_t (or
:
cplusplus-sig-bounces+matthew.scouten=tradingtechnologies@python.org
[mailto:cplusplus-sig-bounces+matthew.scouten=tradingtechnologies@py
thon.org] On Behalf Of Haoyu Bai
Sent: Tuesday, March 17, 2009 1:08 PM
To: Development of Python/C++ integration
Subject: [C++-sig] Some thoughts on py3k
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 situat
25 matches
Mail list logo
