Regarding PEPs 576 and 580. Over the new year, I did a thorough analysis of possible approaches to possible calling conventions for use in the CPython ecosystems and came up with a new PEP. The draft can be found here: https://github.com/markshannon/peps/blob/new-calling-convention/pep-9999.rst
I was hoping to profile a branch with the various experimental changes cherry-picked together, but don't seemed to have found the time :(
I'd like to have a testable branch, before formally submitting the PEP, but I'd thought you should be aware of the PEP.
On 24/03/2019 12:21 pm, Nick Coghlan wrote:
With the revised PEP 1 published, the Steering Council members have been working through the backlog of open PEPs, figuring out which ones are at a stage of maturity where we think it makes sense to appoint a BDFL-Delegate to continue moving the PEP through the review process, and eventually make the final decision on whether or not to accept or reject the change.
We'll be announcing those appointments as we go, so I'm happy to report that I will be handling the BDFL-Delegate responsibilities for the following PEPs:
- PEP 499: Binding "-m" executed modules under their module name as
well as `__main__`
- PEP 574: Pickle protocol 5 with out of band data
I'm also pleased to report that Petr Viktorin has agreed to take on the responsibility of reviewing the competing proposals to improve the way CPython's C API exposes callables for direct invocation by third party low level code:
- PEP 576: Exposing the internal FastCallKeywords convention to 3rd
- PEP 580: Revising the callable struct hierarchy internally and in
the public C API
- PEP 579: Background information for the problems the other two PEPs
are attempting to address