Hi @thomas,
still think we need to set the criteria for accepting a JIT, and I assumed this PEP would be that proposal
You’re right here. It is that proposal! We do say in the PEP if the JIT doesn’t meet its goals we should reconsider removing it, and that the goals are the criteria for marking the JIT supported.
I didn’t think we were talking about a PEP for a future JIT, but for the current JIT.
I think there might be a misunderstanding here. This PEP isn’t proposing a new or future JIT. PEP 836 says:
The rest of the JIT (intermediate representation, middle-end/optimizer, and Copy and Patch backend), remain almost completely unchanged from CPython 3.15. In other words, only what the JIT selects to compile is evolving from traces to methods, nothing else is changing from CPython 3.15.
For people who are unfamiliar with recent JIT developments, the design we described might seem like a radical change, but most of it is already in the current CPython main branch! Again, the only change is growing support for methods.
Also my personal opinion: I don’t think the PEP must be strictly confined to the “current” implementation of the JIT with no room for slight changes. There’s no implicit blessing or formal acceptance of the current implementation in the first place (which, I guess is why we are all here now 
). The burden is on the current implementation to show, through a PEP, that it should be kept in main was my understanding of the situation.