Im not sure I even like calling it bureaucracy. It’s a process, yes. But we’re not talking many layers of abstract organizational hell, here. Were talking a fairly direct process of documenting what you are doing and how you are going to do it well enough that others working and depending on the project can understand it, coordinate with it, and have a reasonable degree of confidence that it won’t cause undue problems.

If having to put all that in writing and get a bunch of people to agree feels too burdensome to you, maybe that’s a sign that you would be happier working on something other than core changes to the world’s second most popular programming language.

(edit: That wasn’t meant to be a jab at the core developers working on the JIT. Based on what’s in the public discussion threads, they have been handling things very well throughout the process. It’s unfortunate that the SC let the project get this far before realizing the project had grown well beyond its original PIP’s mandate, and I’m sure that is deeply frustrating to the people leading the project. I know I would not be handling the setback nearly as gracefully as they are.)

▲

vlovich123 5 hours ago | parent | next [-]

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 4 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 3 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 3 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 2 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 4 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.

▲

saghm 4 hours ago | parent | prev [-]

> Im not sure I even like calling it bureaucracy. It’s a process, yes. But we’re not talking many layers of abstract organizational hell, here. Were talking a fairly direct process of documenting what you are doing and how you are going to do it well enough that others working and depending on the project can understand it, coordinate with it, and have a reasonable degree of confidence that it won’t cause undue problems.

Bureaucracy doesn't definitionally mean Kafkaesque. It's popular to hate on it, but good or neutral bureaucracy does exist.

▲

bunderbunder 4 hours ago | parent [-]

It doesn’t have to mean kafkaesque, but it does mean governance through layered hierarchies and fixed procedures.

In this case a single committee directly engaged with both core developers and the community, through a fairly open process, explicitly bent several of their own official rules to suit the occasion, and indicated cases where further flexibility might be needed depending on how things develop.

I would call that a pretty stellar example of non-bureaucratic governance.

▲

saghm 2 hours ago | parent [-]

Fair enough. I was reacting more to the "organizational hell" part and didn't focus as much on the "layers" part.

	▲	bunderbunder 2 hours ago \| parent [-]
		I have a hard time seeing it as organizational hell, either? From the outside, it looks like the process went smoothly and reached a decision in about half the time they originally estimated. It’s true that that decision didn’t involve everybody getting their way. But that’s not organizational hell, that’s just organization. If you don’t want to contend with other people’s competing interests, the solution to that is solo development.