Hi Brett,
On 26/05/2021 3:56 am, Brett Cannon wrote:
On Tue., May 25, 2021, 12:58 Guido van Rossum, <gu...@python.org
<mailto:gu...@python.org>> wrote:
On Tue, May 25, 2021 at 12:34 PM Brett Cannon <br...@python.org
<mailto:br...@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_cvQUwO2WWsaySyCmIy9nj9by4JKnkbiPCqtluLP3Mg
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/3FTLC7G5A4FA3MZDWX5W2MWDFCPBXSCA/
Code of Conduct: http://python.org/psf/codeofconduct/
