What's the status of PEP 659 (Specializing Adaptive Interpreter)?

Hello,
What’s the status of PEP 659 (Specializing Adaptive Interpreter)?
Currently it’s marked as Informational, which means it:

describes a Python design issue, or provides general guidelines or information to the Python community, but does not propose a new feature. Informational PEPs do not necessarily represent a Python community consensus or recommendation, so users and implementers are free to ignore Informational PEPs or follow their advice.

However, PEP 659 does propose a new feature (albeit an internal one). Furthermore, it looks like the feature is already implemented, and there’s even another CPython-specific PEP in the works that depends on it. CPython implementers can’t really ignore it.

Shouldn’t it be switched to Standards Track and retroactively accepted?

cc @markshannon, @guido

2 Likes

I originally made it a draft informational PEP as that seemed to be the consensus at the time.

I guess it depends on what we mean by a feature?
A language feature? In that case, PEP 659 is informational.
An otherwise surface visible feature, like a command line flag? Again, PEP 659 is informational.
A feature who’s presence can be detected using profiling and monitoring tools? Then yes, it is a feature, but so are a lot of other things that don’t have PEPs.

I want to make sure that the Specializing Adaptive Interpreter is properly explained and documented.
Where that explanation and documentation lives, I don’t mind.

2 Likes

Even a feature meant for core devs, who can use it to speed things up, could be a good PEP.
I’m picking on this PEP because:

  • PEP 669 (Low Impact Monitoring) builds on it. I don’t think it shouldn’t build on a draft. (Also, hopefully a PEP for a change that’s used in another proposal is up-to-date – something I wouldn’t necessarily expect from a Draft/Informational text.)
  • it looks like a good text to explain technical reasons behind the speedup in 3.11. IOW, it’s good for marketing :‍)

It looks like you wouldn’t object to moving it to Standards Track. Would you mind if I made the python-dev post and submitted to the SC?

That sounds fine, if you give me a day or so to update the PEP to reflect our current design first.

2 Likes

@encukou

I updated the PEP PEP 659: Update to describe inline caches by markshannon · Pull Request #2462 · python/peps · GitHub, but it looks like the next step never happened.

Should I do it, or do you want to?

Ah, I didn’t realize that change made the PEP up-to-date. Thanks!
I submitted it to the SC.