The problem is that clearly documenting all details as required in the PEP is at odds with complicated new features like a JIT where all the details can’t be known and have to be decided on as they are realized. Process / bureaucracy is at direct odds with experimentation.

▲

bunderbunder 5 hours ago | parent | next [-]

But they weren’t asking for all the implementation details. They were asking for a clearly stated scope, success criteria, support plan, etc.

As they themselves pointed out, the problem isn’t that there’s anything wrong with an open-ended experiment. It’s just that open-ended experimentation doesn’t belong in main, of all places. They have an ongoing duty to ensure that a critical piece of global infrastructure remains stable and trustworthy to consider.

▲

cogman10 4 hours ago | parent [-]

> clearly stated scope

The scope of a JIT is the entire python runtime. Not at the beginning, it can be more narrow, but certainly it can evolve to cover everything. JITs touch everything.

> success criteria

Impossible to measure. JITs don't universally make things faster and unless the SC was willing to accept "some programs will see around x% improvement" then it would be impossible to actually give them the criteria they want. There's a reason C++ compilers and their optimizations aren't defined by the ISO committee.

> support plan

Like most JITs, support for a JIT is an ongoing and ever evolving process. What's needed depends entirely on what's needed today. You usually need more than 1 or 2 dev working on it, which may be the issue here.

> It’s just that open-ended experimentation doesn’t belong in main, of all places.

Very strong disagree. That's simply the nature of performance optimizations for JITs. They belong on main because new optimizations and heuristics will always be generated. The role of doing a compiler is a long term experiment in performance, seeing what your runtime is currently doing and how it's being used and tweaking it to work better.

pypy isn't in a worse place because it's been running a longterm performance experiment.

> They have an ongoing duty to ensure that a critical piece of global infrastructure remains stable and trustworthy to consider.

None of the things mentioned actually do that, other than perhaps a support plan. There are plenty of critical infrastructure projects who all can manage to develop JITs. Python is the special snowflake that has decided to do JIT development incorrectly.

This is a runtime optimization/implementation detail. It's foolish to send it through a committee approval process. That's why you won't be able to find a single language with a JIT or advanced optimizations that has do it by committee.

▲

bunderbunder 4 hours ago | parent | next [-]

And yet, not introducing unnecessary chaos into the CPython project remains important.

Perhaps these priorities were always irreconcilable.

Perhaps that’s why the existence of competing Python JIT projects that weren’t trying to commit directly into CPython’s main branch kept coming up in the conversation.

▲

ModernMech 4 hours ago | parent | prev [-]

In that case I can understand why it's not a fit for Python. The risks you're describing are more what a brand new language would face: universal scope, impossible to measure success, no support plan... sounds like a nightmare in a mature product. If that's actually what it means to add a JIT to Python, the SC is doing its job by steering Python around this quixotic task.

> This is a runtime optimization/implementation detail.

I view JITs as a critical architectural component. Like you said, it impacts the whole system. Optimization and implementation details don't usually do that.

▲

vlovich123 3 hours ago | parent [-]

The problem is that “Python” the language includes native poorly isolated FFI interfaces exposed by CPython. So the language isn’t “Python” but CPython. That’s why alternate implementations like PyPy haven’t seen adoption despite having a very mature JIT while languages like JavaScript have JITs that put CPython’s performance to shame.

	▲	bunderbunder 3 hours ago \| parent [-]
		It’s also part of why Python has been so successful in many domains. I was there for Python’s takeover of the data space, and I got quite used to porting things from Java (static, JIT, decent at multithreading) to Python (dynamic, interpreted, GIL) and realizing substantial performance improvements in the process. It’s kind of wild how nice Python’s C extension system, which enables basically zero cost interop with native code, is for certain purposes. It supports a situation that’s comparable to the games industry’s tradition of putting a Lua or Lisp tip on top of a C++ iceberg.

▲

jeremyjh 5 hours ago | parent | prev [-]

What are you basing this statement on?

The experiments had long been done. The topic at hand was including it as a core feature.