[M.-A. Lemburg] > Hmm, isn't the idea of having compile time options to give > people a chance to eliminate the feature altogether ? That may be idea for some symbols; e.g., I suppose HAVE_UNICODE is of that nature, although PythonLabs never tests with that disabled either. WITH_CYCLE_GC wasn't of that nature. Like pymalloc before it, cyclic gc was *thought* to be such a large change that it would be prudent to leave cyclic gc off for a release, but give adventurous people a symbol they could use to try it. WITH_CYCLE_GC was enabled by default in the first alpha release to get it some exercise. That didn't turn up any significant problems, so we left it on in the next alpha release too. Still no problems, so we left it on for all the alphas releases. Still no problems, so we left it on for all the beta releases. Still no problems, so we concluded "screw this, let's leave it enabled for the final release too". So the purpose for which WITH_CYCLE_GC was introduced went away before anyone had a chance to use it for that purpose. > I'm thinking in terms of memory footprint of the running > interpreter and its binary. Platforms like e.g. Palm > or Pocket PC are very touchy about this. Embedded devices > even more. I don't buy this. I don't work on embedded devices in this incarnation, and from what I've seen the people who do aren't helped at all by people who don't guessing about what they might need. If people on embedded devices need help in the core, they can speak for themselves, and get the help they *really* need. > How much memory footprint would removing the #ifdefs > cause on average ? 6, give or take.
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