[me] > > Maybe because other macros are often disallowed in (3rd party) > > extensions, the reason being that the macros dig in the internal > > representation which isn't guaranteed to be binary compatible? It > > would make sense that the same rules applies to the Unicode macros in > > 3rd party extensions. > > Which macros would that be ? I modelled the macros in the > Unicode implementation after those of the string > implementation. And those macros are certainly used in > a lot of 3rd party extensions. I take it back. We're anal about binary compatibility in part because of this. There are (or were? it's changed so much!) a few macros in the memory allocator API that were not supposed to be used except in core code; I think I was thinking of those. > I guess, having the macros in the header files without an > explicit warning marks them as public interface. That's how > I have used them in tons of code and I think that I'm not > alone in using this approach. If there was a warning in the docs, that would prove you wrong, but fortunately for you there isn't. :-) > I think that the fact that Michael is seeing breakage is > a good thing. Otherwise, he would probably not have noticed > that RedHat chose to use the wide build as default. Exactly. --Guido van Rossum (home page: http://www.python.org/~guido/)
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