Hi Brett, On 26/05/2021 3:56 am, Brett Cannon wrote:
On Tue., May 25, 2021, 12:58 Guido van Rossum,
mailto:guido@python.org> wrote: On Tue, May 25, 2021 at 12:34 PM Brett Cannon
mailto:brett@python.org> wrote: I personally think it should be a Standards Track PEP. This PEP isn't documenting some detail like PEP 13 or some release schedule, but is instead proposing a rather major change to the interpreter which a lot of us will need to understand in order to support the code (and I do realize the entire area of "what requires a PEP and what doesn't" is very hazy).
Does that also mean you think the design should be completely hashed out and approved by the SC ahead of merging the implementation? Given the amount of work, that would run into another issue -- many of the details of the design can't be fixed until the implementation has proceeded, and we'd end up with a long-living fork of the implementation followed by a giant merge. My preference (and my promise at the Language Summit) is to avoid mega-PRs and instead work on this incrementally.
Now, we've done similar things before (for example, the pattern matching implementation was a long-living branch), but the difference is that for pattern matching, the implementation followed the design, whereas for the changes to the bytecode interpreter that we're undertaking here, much of the architecture will be designed as the implementation proceeds, based on what we learn during the implementation.
Or do you think the "Standards Track" PEP should just codify general agreement that we're going to implement a specializing adaptive interpreter, with the level of detail that's currently in the PEP?
This. Having this as an informational PEP that's already marked as Active seems off somehow to me. I guess it feels more "we're doing this" (which I know isn't intended) rather than "this is our plan, what do you all think? All good?"
The PEP is a "we're doing this" document. Maybe it shouldn't be a PEP at all? I've changed its status to "draft" for now. I want to document what we are doing as publicly as possible and a PEP seems like a good way to do that. I also want to reiterate that the PEP doesn't propose changing the language, libraries, Python API or C API in any way. It is just information about how we plan to speed up the interpreter.
I don't recall other standards track PEPs that don't also spell out the specification of the proposal in detail.
I also am not aware of a PEP that's proposed restructuring the eval loop like this either. 😉 I'm personally fine with the detail and saying details may shift as things move forward and lessons are learned based on the scope and updating the PEP accordingly. But that's just me and I don't know if others agree (hence the reason I'm suggesting this be Standards Track).
Suppose it were a standards PEP, what would that mean if it were rejected? Rejection of a PEP is a choice in favor of an alternative, but what is that alternative? You can't simply say the "status quo" as that would implicitly prevent any development at all on the bytecode interpreter. Cheers, Mark. p.s. For those not at the language summit, here's my grand plan for CPython: https://docs.google.com/presentation/d/1_cvQUwO2WWsaySyCmIy9nj9by4JKnkbiPCqt...