Le 09/11/2011 23:45, "Martin v. Löwis" a écrit :
After a quick search on Google codesearch (before it disappears!), I don't
think that "encoding" a Unicode string to its internal PEP-393 representation
would satisfy any program. It looks like wchar_t* is a better candidate.
Ok. Making it Py_UNI
> After a quick search on Google codesearch (before it disappears!), I don't
> think that "encoding" a Unicode string to its internal PEP-393 representation
> would satisfy any program. It looks like wchar_t* is a better candidate.
Ok. Making it Py_UNICODE, documenting that, and deprecating the
Le mercredi 9 novembre 2011 22:03:52, vous avez écrit :
>
> > Should we:
> > * Drop this codec (public and documented, but I don't know if it is
> > used) * Use wchar_t* (Py_UNICODE*) to provide a result similar to
> > Python 3.2, and
> >
> > so fix the decoder to handle surrogate pairs
> >
> The unicode_internal decoder doesn't decode surrogate pairs and so
> test_unicode.UnicodeTest.test_codecs() is failing on Windows (16-bit
> wchar_t).
> I don't know if this codec is still revelant with the PEP 393 because the
> internal representation is now depending on the maximum character
