On: Python JIT project was asked to pause development

[mwkaufma]

>> While the intent is not to call for competing proposals, we believe that now is a good time to discuss and propose alternative proposals as well.

lol

>> For example, rather than proposing one single concrete JIT implementation, it may make more sense for the PEP to describe a JIT infrastructure that can support multiple implementation strategies.

poison-pill requirement

>> We are setting a window of six months for a PEP to be submitted and resolved. If no such PEP is accepted within that window, the JIT code must be removed from the main branch

so it's going to be removed from the main branch

[sidewndr46 → mwkaufma]

Without a doubt, a great way to kill any project is to add unrelated and ambitious technical requirements to the project. This opens it up to an avalanche of discussion and feedback and almost certainly will kill it off

[scott_w → mwkaufma]

No, it’s a simple request to fully investigate the options before committing a massive piece of work to Python. We’ve seen bad implementations of things land before and now live forever. And frankly, if the team can’t pull together a strong maintenance plan, it can’t be allowed to remain in main.

[pjmlp → scott_w]

So it will join PyPy and GraalPy in the corner.

Python JIT history is full of drama, and no, Smalltalk, Common Lisp, Interlisp-D, SELF are just as dynamic if not more.

[stevefan1999 → pjmlp]

Honorable mention: https://github.com/tonybaloney/Pyjion

[ck45 → stevefan1999]

Not to forget Unladen Swallow Which even tried to merge into CPython: https://peps.python.org/pep-3146/

[scott_w → pjmlp]

JIT in CPython has nothing to do with PyPy or GraalPy: it's its own thing. If they can't get a PEP accepted within 6 months then it's best that the code isn't weighing on the main codebase until an approach can be agreed, at which point work integrating it into main can restart. It's not an all-or-nothing situation.

[pjmlp → scott_w]

> JIT in CPython has nothing to do with PyPy or GraalPy: it's its own thing.

I haven't said otherwise.

[scott_w → pjmlp]

So why did you bring them up…

[pjmlp → scott_w]

My words were

> So it will join PyPy and GraalPy in the corner.

If you cannot understand what that means, I am not a English professor.

[scott_w → pjmlp]

I understand your words, I don’t understand why you think they’re relevant to the discussion.

[pjmlp → scott_w]

Relegated to niche users, just like the other two.

[scott_w → pjmlp]

Except it’s not. The intention of JIT in CPython is to make it into the main branch feature complete. If they can’t get the necessary support then it won’t be relegated to niche uses, it’ll be abandoned and need a new effort to get off the ground.

Not even remotely the same context.

[pjmlp → scott_w]

It certainly is the same context, given the Python culture to ignore JITs, rewrite in C, and call it "Python" libraries.

We have been here several times, versus the other dynamic languages, and it has nothing to do with the usual excuse how dynamic Python happens to be.

[scott_w → pjmlp]

I don’t know why you keep bringing up Python being dynamic, it’s not particularly relevant. What matters is the content of the request which is to outline how the feature should work and be maintained over time before it can be accepted.

What’s your position? That we should allow an extremely complex system into Python with:

- No clear design goal?

- No maintenance plan?

- No discussion with the steering committee?

PyPy and Jython, and others are not built by the Python team and there has never been a suggestion that any of these systems would be part of CPython.

So again, I still don’t see how different implementations of Python are relevant to the discussion about CPython.

[pjmlp → scott_w]

They are relevant for the Python culture towards JIT adoption.

[onlyrealcuzzo → pjmlp]

And Ruby

[petre → onlyrealcuzzo]

Ruby has not one, two, but three JITs.

[pjmlp → petre]

Actually more, are you country JRuby, TruffleRuby and RubyMotion.

[throwaway81523 → pjmlp]

CL is definitely less dynamic than Python. Dunno about the others.

[pjmlp → throwaway81523]

Why do you think so?

All of them support changing anything at anytime, killing all JIT assumptions, and forcing it to redo the world.

Stop execution, land into the debugger, change whatever code you feel like during the debugging session and then redo last statement, continuing execution.

There are also ways to do this on fly, without necessarily using the debugger.

[dataflow → scott_w]

> We’ve seen bad implementations of things land before and now live forever.

Er, doesn't that depend on how leaky the abstraction is? How often have you seen a JITted language be unable to swap in a new JITter due to some sort of unintended coupling?

[scott_w → dataflow]

If it’s so easy then writing a PEP and getting it approved in 6 months will be trivial.

[dataflow → scott_w]

"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.

[scott_w → dataflow]

"It" is the PEP that the Steering Committee are asking for. I'm not on the committee and I don't know how to write a JIT to meet the requirements.

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?

[LtWorf → scott_w]

> and now live forever.

What forever are you talking about? Python removes stuff every single release.

[scott_w → LtWorf]

Default list/dict arguments is the one that comes to mind. Yes, I know why it happens, no, it’s still bad because it trips up every beginner.

[tasuki → scott_w]

Why does it happen?

[NekkoDroid → tasuki]

Default arguments are only evaluated once and assigned the same instance to every call that doesn't specify that argument. So when you assign a new list as a default argument and then append to that list, the next call will already have one element in that list. So what you need to do is have it "None-able" and within the function create a new list.

[LtWorf → NekkoDroid]

You can use anything immutable like a string, a number, a tuple of immutables, a frozendict, any dataclass with frozen=True, and so on.

No need to do the annoying if x is None.

[tasuki → NekkoDroid]

Yes I know as much, but why? Is it for speed? Python is slow anyway, so no big deal. Incompetence? Malice perhaps?

[LtWorf → tasuki]

It's just because the `def xxx()` part gets executed once when the module is loaded so the default arguments get created then. It's not really a design choice.

If you declare a function inside a for loop with the default argument set to a list, it will be re-declared at every iteration of the loop and the list of the default argument will be a new instance every time.

[tasuki → LtWorf]

> It's just because the `def xxx()` part gets executed once when the module is loaded so the default arguments get created then.

I understand as much.

> It's not really a design choice.

That explains it then. Pretty damning though, no?

[NekkoDroid → tasuki]

I don't have any evidence for my theory, but I assume it is because arguments are processed mostly on the function side instead of the call site.

My assumption just makes sense when all the function really gets is "a list of positional arguments and a dict of keyword arguments" (ala `*args, **kwargs`) that is "deconstructed" to the named variables on the function side. Then the function never gets the default value passed and fills it in before executing the body. Therefore it needs some value to assign and that value is determined when parsing the function definition.

So effectively I want to say that I think instead of the default value being passed at the call site (which is how C++ for example does it by inserting the expression inplace of a specified value) it is filled in by the function before executing the body.

In the end this is just a guess, but that is my working hypothesis.

[ptx → NekkoDroid]

Function definitions in Python are just statements that are executed. When you execute the "def" statement, the default values are evaluated.

You can try it in the REPL:

  >>> def f(foo=print("Executing def statement!")):
  ...   print("Executing function body.")
  ... 
  Executing def statement!
  >>> f()
  Executing function body.

There's a fairly straight-forward explanation of this in the documentation: https://docs.python.org/3/reference/compound_stmts.html#func...

"Default parameter values are evaluated from left to right when the function definition is executed. This means that the expression is evaluated once, when the function is defined, and that the same “pre-computed” value is used for each call."