On Tue., May 25, 2021, 12:58 Guido van Rossum, <gu...@python.org> wrote:
> On Tue, May 25, 2021 at 12:34 PM Brett Cannon <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?" 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). -Brett > -- > --Guido van Rossum (python.org/~guido) > *Pronouns: he/him **(why is my pronoun here?)* > <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/> >
_______________________________________________ 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/JSKR5GS7OSXYKZFQAYZ4IVXZCC5NXIEX/ Code of Conduct: http://python.org/psf/codeofconduct/
