On Wed, May 26, 2021 at 4:23 AM Mark Shannon <m...@hotpy.org> wrote:

> 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.
>

Thanks!


>
> 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.
>

Sure, but it isn't a minor change either; if it was then you would have
done it already. 😉 This is an architectural shift in how the interpreter
works, so it isn't a minor thing.


> >
> >
> >     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?
>

Then we don't do it.


> Rejection of a PEP is a choice in favor of an alternative, but what is
> that alternative?
>

The status quo.


> You can't simply say the "status quo" as that would implicitly prevent
> any development at all on the bytecode interpreter.
>

I don't think that logic holds; if *your *approach happened to be rejected
in terms of how to change how the interpreter works it doesn't mean that
*no* approach would be accepted (and you can tweak this to be about
performance or anything else). PEPs are not submitted where it's "pick from
these 2 options" or "pick this or you can never touch the topic/idea again".

I think this is all a question of process and how do we want to handle
these sort of architectural changes that don't necessarily impact APIs (and
thus users directly), but do impact all of us from a perspective of
maintenance and understanding? Typically we haven't worried about it
because quite frankly none of us have had the time to really tackle
something this large or it was so speculative it was done outside of the
repo (e.g. gilectomy). If people want to stick with informal consent, then
great! If people want to have a more formal discussion, that works too! But
my point is this falls into an odd gray area in our overall process that I
am suggesting we try to figure out.

-Brett


>
>
> 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/KUOS5LGD5WBWTEBATHRUFK47WNWZGXY5/
Code of Conduct: http://python.org/psf/codeofconduct/

Reply via email to