|
|
|
|
|
by dataflow
5 days ago
|
|
"It"? What are you talking about? You didn't answer my question at all. I said if you have a second JIT to swap to in the future, you should be able to switch to that without breaking apps and not be forced to keep this implementation forever -- because JITs don't tend to expose APIs or leaky abstractions to the code, and it's not hard to ensure this one doesn't either. I asked you if you've ever seen another language that actually had another JIT to switch to but wasn't able to. Instead of addressing my point, you replied that it should be easy to write something else (a second JIT, "general infrastructure" for JITs, or whatever suits your fancy) and get it approved? What? No that is not, and I never claimed that would be easy. And if it has to be approved by someone who responds like this, it clearly wouldn't be fun either. |
|
What I don't understand is "what is your position?" Is is that writing a PEP is unnecessary because adding a JIT to Python could trivially meet the goals you state?
My position is simple: adding a JIT is a major change to the language, so of course it should undergo a PEP and answer the major questions that the steering committee put forward. If you think those questions are trivial, then that's ok. Just answer them in the PEP.
> And if it has to be approved by someone who responds like this, it clearly wouldn't be fun either.
I really don't see why you'd think I would be representative of the steering committee's opinions or attitudes. Do I share a name with one of the members?