Guido van Rossum wrote:
Hm, the "u" argument parser is a nasty one to catch. How likely is this to be the *only* reference to Unicode in a particular extension?
It is not very likely but IMHO possible for e.g. extensions which rely on the fact that wchar_t == Py_UNICODE and then do direct interfacing to some other third party code.
I guess one could argue that extension writers should check for narrow/wide builds in their extensions before using Unicode.
Since the number of Unicode extension writers is much smaller than the number of users, I think that this apporach would be reasonable, provided that we document the problem clearly in the NEWS file.
OK. I approve.
Great ! I'll go ahead and fix unicodeobject.h.
Hmm, that would probably not make UCS-4 builds very popular ;-)
Do you have any reason to assume that it would be popular otherwise? :-) :-) :-)
Oh, I do hope that people try out the UCS-4 builds. They may not be all that interesting yet, but I believe that for Asian users they do have some advantages.
These warnings should use the warnings framework, by the way, to make it easier to ignore a specific warning. Currently it's a hard write to stderr.
Using the warnings framework would indeed be a good idea (many older extensions work just fine even with later API levels; the warnings are annoying, though) !
I'm not going to make the change, but it should be a two-liner in Python/modsupport.c:Py_InitModule4().
I'll look into this as well.