[scott_w]

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]

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]

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

[ck45]

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

[scott_w]

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]

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

I haven't said otherwise.

[scott_w]

So why did you bring them up…

[pjmlp]

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]

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

[onlyrealcuzzo]

And Ruby

[petre]

Ruby has not one, two, but three JITs.

[pjmlp]

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

[throwaway81523]

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

[pjmlp]

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]

> 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]

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

[dataflow]

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

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

> and now live forever.

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

[scott_w]

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]

Why does it happen?

[NekkoDroid]

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]

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]

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

[LtWorf]

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.