On 24/07/2014 9:42 pm, Nick Coghlan wrote: > On 25 Jul 2014 03:51, "Brett Cannon" <brett at python.org> wrote: > >> 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. > > 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). The implementation of PEP 432 would be great. > 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. Is there any way for somebody you don't trust :) to be able to help move it forward? Phil
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4