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) ! > > Exactly. > > 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. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Consulting & Company: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4