[Python-Dev] Structural cleanups to the main CPython repo (original) (raw)

Nick Coghlan ncoghlan at gmail.com
Wed May 29 04:19:55 CEST 2013

On Wed, May 29, 2013 at 2:47 AM, "Martin v. Löwis" <martin at v.loewis.de> wrote:

Am 28.05.13 18:20, schrieb Antoine Pitrou:

Le Tue, 28 May 2013 23:07:37 +1000, Nick Coghlan <ncoghlan at gmail.com> a écrit :

It was deliberate - a big part of PEP 432 is making sure that all the interpreter state lives in the interpreter state (as part of the config struct).

It sounds a bit exagerated. We have encoders and decoders in the same (C) modules, compressors and decompressors ditto. Why not keep initialization and finalization in the same source file too? I can sympathize with the motivation. Unlike encoders and decoders, it is very tempting to put interpreter state into global variables. With encoders and decoders, it's clear that globals won't work if you have multiple of them. With interpreter state, it's either singletons in the first place, or the globals can be swapped out when switching interpreters. By splitting initialization and finalization into distinct translation units, you make it much more difficult to introduce new "hidden" variables.

Yep, that was a key part of my motivation (the other part was also to find out what global state we already had by making the build blow up for anything that was static and referenced by more than just the bootstrapping code). The part I didn't think through when I did it in a long-lived branch was just how much of nightmare it was going to make any merges that touched pythonrun.h or pythonrun.c :)

I'd also be open to a setup with a single "lifecycle.h" header file, which was split into the bootstrap and shutdown implementation units, since that makes it easier to check that the appropriate setup/finalize pairs exist (by looking at the combined header file), while still enlisting the build chain's assistance in avoiding hidden global state.

Anway, I'll come up with some specific patches and put them on the tracker, starting with moving the source files for the binary executables and making the simpler pythonrun/lifecycle split. I can look into splitting lifecycle.c into separate bootstrap and shutdown translation units after those less controversial changes have been reviewed (the split may not even be all that practical outside the PEP 432 branch, since it would involve exposing quite a few currently static variables to the linker).

Cheers, Nick.

-- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia

More information about the Python-Dev mailing list