This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author lemburg
Recipients amaury.forgeotdarc, bupjae, ezio.melotti, lemburg, vstinner
Date 2009-02-03.13:12:03
SpamBayes Score 4.1915071e-10
Marked as misclassified No
Message-id <498842A1.3030900@egenix.com>
In-reply-to <1233664789.97.0.674612431629.issue5127@psf.upfronthosting.co.za>
Content
On 2009-02-03 13:39, Amaury Forgeot d'Arc wrote:
> Amaury Forgeot d'Arc <amauryfa@gmail.com> added the comment:
> 
> Since r56395, ord() and chr() accept and return surrogate pairs even in
> narrow builds.
> 
> The goal is to remove most differences between narrow and wide unicode
> builds (except for string lengths, indices or slices)
>
> To address this problem, I suggest to change all functions in
> unicodectype.c so that they accept Py_UCS4 characters (instead of
> Py_UNICODE). 

-1.

That would cause major breakage in the C API and is not inline with the
intention of having a Py_UNICODE type in the first place.

Users who are interested in UCS4 builds should simply use UCS4 builds.

> This would be a binary-incompatible change; and --with-wctype-functions
> would have an effect only if sizeof(wchar_t)==4 (instead of the current
> condition sizeof(wchar_t)==sizeof(PY_UNICODE_TYPE))

--with-wctype-functions was scheduled for removal many releases ago,
but I never got around to it. The only reason it's still there is
that some Linux distribution use this config option (AFAIR, RedHat).
I'd be +1 on removing the option in 3.0.1 or deprecating it in
3.0.1 and removing it in 3.1.

It's not useful in any way, and causes compatibility problems
with regular builds.
History
Date User Action Args
2009-02-03 13:12:05lemburgsetrecipients: + lemburg, amaury.forgeotdarc, vstinner, ezio.melotti, bupjae
2009-02-03 13:12:04lemburglinkissue5127 messages
2009-02-03 13:12:03lemburgcreate