[Python-Dev] constness of interpreter data

Torne Wuff torne-pythondev at wolfpuppy.org.uk
Mon Sep 1 17:38:17 CEST 2008

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 at wolfpuppy.org.uk
-------------- next part --------------
A non-text attachment was scrubbed...
Name: constness.patch
Type: text/x-diff
Size: 2299 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20080901/54a6b884/attachment-0001.patch>

More information about the Python-Dev mailing list