On Wed, May 29, 2013 at 2:47 AM, "Martin v. Löwis" <mar...@v.loewis.de> wrote: > Am 28.05.13 18:20, schrieb Antoine Pitrou: >> Le Tue, 28 May 2013 23:07:37 +1000, >> Nick Coghlan <ncogh...@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 | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ 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
