This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author ncoghlan
Recipients eric.snow, grahamd, ncoghlan, pitrou, steve.dower, vstinner
Date 2019-02-16.14:20:45
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1550326845.67.0.479548221973.issue22213@roundup.psfhosted.org>
In-reply-to
Content
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.
History
Date User Action Args
2019-02-16 14:20:45ncoghlansetrecipients: + ncoghlan, pitrou, vstinner, grahamd, eric.snow, steve.dower
2019-02-16 14:20:45ncoghlansetmessageid: <1550326845.67.0.479548221973.issue22213@roundup.psfhosted.org>
2019-02-16 14:20:45ncoghlanlinkissue22213 messages
2019-02-16 14:20:45ncoghlancreate