Anyone who’s worked in incident response will tell you why you’re wrong.

Tweaking the GC while the system was functionally broken is the worst time to do it. Correct incident response is revert first, figure out how to fix it later.

The difference being this is not a live system and thus incident response is very different. Applying best practices from incident response to development of a language is simply incorrect

You're simply incorrect here. The GC was in versions 3.14.0 to 3.14.4. See https://docs.python.org/3/whatsnew/3.14.html#whatsnew314-inc...

On what planet is the currently released version of any software "not a live system?"

Do you live on a planet where the Python language maintainers are deploying Python into your servers or managing them? Do you live on a planet where a new version of Python being released gets instantly and automatically deployed into your systems without testing and validation?

You are responsible for that, not them. And if Python 3.13 is fine for you and you report a performance regression for 3.14, you can still stay on 3.13. And as you say, it was introduced in a new release. What happens when the other side goes and says “3.14.5 regressed on the GC pause times and my p95 web server latencies went up. Please revert”? At least one side can make the case “performance was changed on a major release of Python boundary” while the other is changing the performance on a minor release boundary. It’s an arbitrary decision that speaks to the politics of the organization and less about a well reasoned technical plan.

This makes sense because these companies want to become large companies and contract with large companies. Large companies, by and large, try to follow the law (while trying to bend it to the limit) because they're aware they have a big target on their back and no CEO wants to be on the front page of the papers for tanking a company in such a stupid fashion.

That's why you work with your Legal/Compliance Team to make sure you stay in line. They can explain when a rule applies and when it doesn't. This needs the engineering side to be able to explain what's happening, and translate it into the business process as closely as possible, and the legal side to be able to apply the law to the case.

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.

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.

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

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

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.

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

I haven't said otherwise.

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.

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

Relegated to niche users, just like the other two.

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.

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.

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.

They are relevant for the Python culture towards JIT adoption.

And Ruby

Ruby has not one, two, but three JITs.

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

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

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.

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

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

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

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

> and now live forever.

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

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.

Why does it happen?

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.

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.

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

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.

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

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.

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

Pretty sure there’s a middle ground between “forced sterilisation” and “boil humans to death in 50°C heat,” don’t you?

Sterilize half of humans, and boil the other half?

I think it’s good to remember that, just 2 years ago, we were having conversations with people convinced LLMs were intelligent and possibly sentient. It’s really good to a) point out that they’re not demonstrating general intelligence and b) why they aren’t a good fit for this type of problem.

Are they voluntarily participating if they’re being lied to about what they’re participating in? What distinguishes the whole thing from fraud?

> Not scientific but I enjoy actually going somewhere. Jogging you can get to places in your neighborhood, but cycling I can get to places in my region.

You just reminded me of my holiday to Biarritz in April where my wife received a text: "Should be back in about an hour or so, I'm just riding back from Spain."

While I haven't given up driving, the fact that I don't rely on it to commute (granted I work from home rather than cycling) means that when I do drive, my relative frustration is really low. About the only thing that annoys me is dangerous driving... for obvious reasons!

Same situation, working from home, although my city has decent public transport so even going downtown is easier without driving. But now when I need to drive for whatever reason, I get frustrated at having to drive. I'll complain about having to take the car, that why can't they put a bus route here, why is it the train doesn't stop at the station I need etc etc.

Which actually surprised me, when my SO said to me: but I thought you liked driving? When we first met you were always working on your car...

Oh yeah. I did, didn't I? It just kinda happened without me realizing it.

Yet their account was restored so clearly GCP themselves disagree with you.

Or they fixed the issue to remain compliant so GCP would restore access. Again, I know it's fashionable to hate on Google here, but there are always 2 sides to every story.

That’s not what you just claimed. I’ve quoted you below:

> Or..they couldn't remain compliant with one of the strictest cloud vendors' policies.

Which is it? They can comply or they can’t? Both sides can’t be true at the same time.

Just saying either way is possible unless both sides of the story are out in the open. You seem to start from a point of view of malice, I'm simply suggesting possible alternatives.

Except one way isn’t possible because the facts and logic tell you it’s not.

Being open minded is good but don’t keep it so open your brain leaks out.