[Python-Dev] Structural cleanups to the main CPython repo

[Nick Coghlan]

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