Just because there's a lot of shit Python code out there, doesn't mean people who want to write clean, performant Python code should suffer for it.

I haven’t seen or used a global more than once in my 20 years of writing Python.

Web services in Python that want to handle multiple comcurrent requests in the same interpreter should be using a web framework that is designed around that expectation and don't use a global request context object, such as FastAPI.

Because literally every import, class definition, or function definition that you make at top-level is a global.

Now some people do in fact do all those things inside a function, too, and then call that function as the only thing that actually happens globally. And I've done such hacks myself to squeeze the last few % of perf out of CPython on the very rare occasions where you need to do that but dropping into C is not an option. But that's certainly not idiomatic Python.

I have not been seeing good Python code, for sure. Hopefully it's not a majority. But it's very far from non-existent.

  def f():
      l = [0]
      for i in range(100000000):
          l += [2]
      return l

  x = f()
  print(x[0])

  3.9:                    8.6s

  3.14:                   8.7s

  3.14 (free-threading): 11.6s

3.9: 2.78

3.14: 3.86

3.14t: 3.91

This is a silly benchmark though. Look at pyperformance if you want something that might represent real script/application performance. Generally 3.14t is about 0.9x the performance of the default build. That depends on a lot of things though.

This benchmark demonstrates that global variables are not needed to find severe regressions.

If you don't want to use global variables just add the result of f to x and stop using the global variable, i.e.

   x += f()

Variables always start with a lowercase letter in idiomatic Python unless they're constants or types.

Using single-letter uppercase for variables is not unusual in ML Python code, but that also happens to be one of the worst ecosystems when it comes to idiomatic Python and general code quality.

Even though technically, everything in Python is an object, I feel strongly that programmers should avoid OOP in Python like the plague. Every object is a petri dish for state corruption.

Thee is a very solid list of reasons to use pure functions with explicit passing wherever humanly possible, and I personally believe there is no comparable list of reason to use OOP. * Stack-allocated primitives need no refcounting * Immutable structures reduce synchronization * Data locality improves when you pass arrays/structs rather than object graphs * Pure functions can be parallelized without locks

But OOP does not necessitate mutable state; you can do OOP with immutable objects and pure methods (except the constructor). Objects are collections of partially-applied functions (which is explicit in Python) that also conceal internal details within its own namespace. It is convenient in certain cases.

But very rarely.

If you want immutability as a lynchpin, you need to look at a different language. This one is very much not designed for it.

But isn't that the point? Previously, pure functions would all lock, so you could only run one pure function at a time. Now they don't.

The question is whether 1+ thread per core with GIL free Python perform as well as 1+ process per core with GIL.

My understanding is that this global is just a way to demonstrate that the finely grained locking in the GIL free version may make it so that preforking servers may still be more performant.

How to write Python code with no globals

And a source other than you saying you should do it this way