<p dir="ltr"><br>
On 25 Jul 2014 03:51, "Brett Cannon" <<a href="mailto:brett@python.org">brett@python.org</a>> wrote:</p>
<p dir="ltr">> The problem with all of this is you are essentially asking for a hook to let you have code have access to the interpreter state before it is fully initialized. Zipimport and the various bits of code that get loaded during startup are special since they are coded to avoid touching anything that isn't ready to be used. So if we expose something that allows access prior to full initialization it would have to be documented as having no guarantees of interpreter state, etc. so we are not held to some API that makes future improvements difficult.</p>

<p dir="ltr">Note that this is *exactly* the problem PEP 432 is designed to handle: separating the configuration of the core interpreter from the configuration of the operating system interfaces, so the latter can run relatively normally (at least compared to today).</p>

<p dir="ltr">As you say, though it's a niche problem compared to something like packaging, which is why it got bumped down my personal priority list. I haven't even got back to the first preparatory step I identified which is to separate out our main functions to a separate "Programs" directory so it's easier to distinguish "embeds Python" sections of the code from the more typical "is part of Python" and "extends Python" code.</p>

<p dir="ltr">> IOW allowing for easy patching of Python is probably the best option I can think of.</p>
<p dir="ltr">Yeah, that sounds reasonable - IIRC, Christian ended up going with a similar "make it patch friendly" approach for the hashing changes, rather than going overboard with configuration options.</p>
<p dir="ltr">Cheers,<br>
Nick.<br>
</p>