[MAL] > Then why do we have a switch to optionally remove the Unicode > support ? I don't know, although I've asked that question myself. People used to be frightened of the Unicode database sizes; I'm not sure they are anymore. > or for disabling interning of strings ? There is no such switch now. There used to be one. Ditto for whether to cache hash values. Ditto whether to "cache-align" hash table entries. At the time those were nuked, Guido also said he wanted COUNT_ALLOCS to disappear (and to act as if it were always #define'd in a Py_TRACE_REFS build), but nobody has gotten to that yet. > or for caching small integers ? There isn't a switch for that either, although there are two undocumented symbols you can #define such that if their sum is <= 0, small ints waste *more* memory than if you leave the code alone. There's no way to disable the unbounded and immortal int free list, and never was. >>> How much memory footprint would removing the #ifdefs >>> cause on average ? >> 6, give or take. > 6 what ? snakes, rabbits, swallows ? You asked an unanswerable (not to mention unparseable) question, I gave a useless yet accurate answer -- if you can rephrase your question in a way that can be answered, attach whatever units you need to make 6 exactly correct <wink>. Although note that since WITH_CYCLE_GC has been #define'd by default since it was introduced, removing its #ifdefery would have no effect on default builds. > I'm missing a concise concept here :-) > > If you want to make life hard for people who want to customize > the interpreter, then you should remove *all* such #ifdefs. If > not, then having the #ifdefs adds important meta-information > to the code. If you don't personally use a specific preprocessor symbol routinely, I won't accept your bare assertion that it makes life easier for anyone. Against that, every preprocessor symbol certainly makes it-- a little to a lot --harder to maintain the code. We almost never hear from anyone that these little nightmares are being used; when we do hear about them, it's almost always from a dabbler who "just tried it" and then complains because Python no longer works (from won't compile to segfaults). Fixing unused code is a waste of time; I won't do it anymore, but I will devote time to getting rid of unused code.
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