> We should probably document where all of these globals lists are > instead of relying on looking for all file level static declarations > or something.
I'm not sure what would be gained here, except for people occasionally (i.e. every three years) asking how they can best get rid of the GIL. > Or would there be benefit to moving things like this to > the interpreter struct so that threads within a single interpreter > call are locked but interpreters can act much more independently? The "multiple interpreter" feature doesn't quite work, and likely won't for a foreseeable future; specifically, objects can easily leak across interpreters. That's actually not a problem for immutable objects, like the strings, but here come the global objects into play which PJE mentions: types, including exceptions. Making them per-interpreter would probably break quite some code. As for the cached strings - it would be easy to make a global table of these, e.g. calling them _PyS__init__, _PyS__add__, and so on. These could be initialized at startup, simplifying the code that uses them because they don't have to worry about failures. Regards, Martin _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com