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 amaury.forgeotdarc
Recipients Rhamphoryncus, amaury.forgeotdarc, bupjae, ezio.melotti, lemburg, vstinner
Date 2010-07-08.23:34:22
SpamBayes Score 0.0009694793
Marked as misclassified No
Message-id <1278632064.34.0.51357937698.issue5127@psf.upfronthosting.co.za>
In-reply-to
Content
> Could you explain what this bit is about ?
> -#if defined(HAVE_USABLE_WCHAR_T) && defined(WANT_WCTYPE_FUNCTIONS)
> +#if defined(Py_UNICODE_WIDE) && defined(WANT_WCTYPE_FUNCTIONS)

On Windows at least, HAVE_USABLE_WCHAR_T is True, this means that Py_Unicode can be converted to wchar_t.  But now that Py_UNICODE_ISSPACE() takes Py_UCS4, it cannot be converted to wchar_t anymore.

Now that the unicode database functions claim to use Py_UCS4, the functions of wctypes.h are usable only if they also support Py_UCS4.

OTOH the symbol WANT_WCTYPE_FUNCTIONS is defined only if ./configure is called with --with-wctype-functions, I don't expect it to be common.
BTW, the comment says that "This reduces the interpreter's code size".  I don't really agree, these functions are two-liners.
History
Date User Action Args
2010-07-08 23:34:24amaury.forgeotdarcsetrecipients: + amaury.forgeotdarc, lemburg, Rhamphoryncus, vstinner, ezio.melotti, bupjae
2010-07-08 23:34:24amaury.forgeotdarcsetmessageid: <1278632064.34.0.51357937698.issue5127@psf.upfronthosting.co.za>
2010-07-08 23:34:23amaury.forgeotdarclinkissue5127 messages
2010-07-08 23:34:22amaury.forgeotdarccreate