libpython2.5.a contains quite a lot of .data that doesn't look like it needs to be writable (my minimal interpreter binary has 105KB of writable allocated data). A lot of these symbols look like they could just be tagged const with no other changes to the interpreter; some of them would require a proliferation of constness. I'm a bit new at this, though, and it's possible that I'm wrong about some/most/all of these, so I'm wondering what people think. Attached is a patch which adds const to the easy ones: * Docstrings for extension functions (PyDoc_VAR in Python.h) * ascii->digit lookup table (_PyLong_DigitValue in longobject.c) * The copyright notice (cprt in getcopyright.c) There are no errors or new warnings introduced in my build by this patch, but I'm only compiling the interpreter itself. If anyone can suggest a reason why any of those shouldn't be const, please do :) Things that take up space that might be const-able with more effort, or might not, I can't tell: * Token names (_PyParser_TokenNames in tokenizer.c) * Module function tables (and ensuing propagation of constness into PyModule_Init etc) * All the type and exception objects Things that take up space but probably aren't const-able unless someone who knows more than me has an idea: * Standard slot definitions (slotdefs in typeobject.c, but the interned string pointers get added at runtime) * The generated tables for the grammar (but the accelerator seems to want to change these at init time) There's probably other things, but I didn't go through the entire symbol table, just started with the big ones :) So, er, is this a remotely sane thing to be doing, and does anyone have suggestions? :) -- Torne Wuff torne@wolfpuppy.org.uk