Nicholas Bastin wrote:
> That makes PyUnicode_FromUnicode() a lot less useful. Well, really,
> not useful at all.
Why do you say that? Py_UNICODE is as good a type to store characters
as any other, and if you happen to have a Py_UNICODE[], you can use
that function to build a unicode object.
>
On May 4, 2005, at 1:39 PM, M.-A. Lemburg wrote:
> Nicholas Bastin wrote:
>> On May 4, 2005, at 4:39 AM, M.-A. Lemburg wrote:
At the very least, if we can't guarantee the internal
representation, then the PyUnicode_FromUnicode API needs to go
away, and be replaced with something
Nicholas Bastin wrote:
>
> On May 4, 2005, at 4:39 AM, M.-A. Lemburg wrote:
>
>>> At the very least, if we can't guarantee the internal representation,
>>> then the PyUnicode_FromUnicode API needs to go away, and be replaced
>>> with something capable of transcoding various unicode inputs into
On May 4, 2005, at 4:39 AM, M.-A. Lemburg wrote:
>> At the very least, if we can't guarantee the internal representation,
>> then the PyUnicode_FromUnicode API needs to go away, and be replaced
>> with something capable of transcoding various unicode inputs into the
>> internal python represent
Nicholas Bastin wrote:
> The documentation for Py_UNICODE states the following:
>
> "This type represents a 16-bit unsigned storage type which is used by
> Python internally as basis for holding Unicode ordinals. On platforms
> where wchar_t is available and also has 16-bits, Py_UNICODE is a
I really don't know. Effbot, MvL and/or MAL should know.
On 5/3/05, Nicholas Bastin <[EMAIL PROTECTED]> wrote:
>
> On May 3, 2005, at 6:44 PM, Guido van Rossum wrote:
>
> > I think that documentation is wrong; AFAIK Py_UNICODE has always been
> > allowed to be either 16 or 32 bits, and the sourc
On May 3, 2005, at 6:44 PM, Guido van Rossum wrote:
> I think that documentation is wrong; AFAIK Py_UNICODE has always been
> allowed to be either 16 or 32 bits, and the source code goes through
> great lengths to make sure that you get a link error if you try to
> combine extensions built with d
I think that documentation is wrong; AFAIK Py_UNICODE has always been
allowed to be either 16 or 32 bits, and the source code goes through
great lengths to make sure that you get a link error if you try to
combine extensions built with different assumptions about its size.
On 5/3/05, Nicholas Bast
The documentation for Py_UNICODE states the following:
"This type represents a 16-bit unsigned storage type which is used by
Python internally as basis for holding Unicode ordinals. On platforms
where wchar_t is available and also has 16-bits, Py_UNICODE is a
typedef alias for wchar_t to enha
