On 4 August 2018 at 08:37, Victor Stinner <vstinner@redhat.com> wrote:
It seems like the PEP 432 proposes an API designed from scratch as the target API. I started from the 28 years old C code and I tried to cleanup the code. Our method is different, so it's not surprising that the result is different :-)
No, you didn't start from the 28 year old C code - you started from the private initial implementation of PEP 432, as per https://www.python.org/dev/peps/pep-0432/#implementation-strategy (and PEP 432 in turn was born from the Python 3.3 changes needed to integrate importlib properly into the __main__ initialisation process) Eric and I merged that [1], because it become apparent while I was working on the core settings management framework that actually migrating individual settings needed to happen in-tree, as the alternative of continuing to maintain it out of tree would at best result in an enormous unreviewable patch, and more likely never result in a patch at all (as the churn rate on CPython was high enough to cause regular conflicts even with the framework branch, let alone once we started migrating individual settings). The current private API doesn't meet some of the original design goals of the PEP, but the time to reconcile that (and figure out whether it's the API design or the implementation that should change) is while we're updating and reviewing the PEP against the current implementation - while everything remained private, it didn't make sense to throw any additional roadblocks in the way of the excellent work you were doing. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia