Nick Coghlan <ncogh...@gmail.com> added the comment:

Steve, you're describing the goals of PEP 432 - design the desired API, then 
write the code to implement it. So while Victor's goal was specifically to get 
PEP 540 implemented, mine was just to make it so working on the startup 
sequence was less awful (and in particular, to make it possible to rewrite 
getpath.c in Python at some point).

Unfortunately, it turns out that redesigning a going-on-thirty-year-old startup 
sequence takes a while, as we first have to discover what all the global 
settings actually *are* :)

https://www.python.org/dev/peps/pep-0432/#invocation-of-phases describes an 
older iteration of the draft API design that was reasonably accurate at the 
point where Eric merged the in-development refactoring as a private API (see 
https://bugs.python.org/issue22257 and 
https://www.python.org/dev/peps/pep-0432/#implementation-strategy for details).

However, that initial change was basically just a skeleton - we didn't migrate 
many of the settings over to the new system at that point (although we did 
successfully split the import system initialization into two parts, so you can 
enable builtin and frozen imports without necessarily enabling external ones).

The significant contribution that Victor then made was to actually start 
migrating settings into the new structure, adapting it as needed based on the 
goals of PEP 540.

Eric updated quite a few more internal APIs as he worked on improving the 
subinterpreter support.

Between us, we also made a number of improvements to 
https://docs.python.org/3/c-api/init.html based on what we learned in the 
process of making those changes.

So I'm completely open to changing the details of the API that PEP 432 is 
proposing, but the main lesson we've learned from what we've done so far is 
that CPython's long history of embedding support *does* constrain what we can 
do in practice, so it's necessary to account for feasibility of implementation 
when considering what we want to offer.

Ideally, the next step would be to update PEP 432 with a status report on what 
was learned in the development of Python 3.7 with the new configuration 
structures, and what the internal startup APIs actually look like now. Even 
though I reviewed quite a few of Victor and Eric's PR, even I don't have a 
clear overall picture of where we are now, and I suspect Victor and Eric are in 
a similar situation.

----------

_______________________________________
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue22213>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Reply via email to