4 ms·

Evil response. Say, "Sure!" and release python v4 with their feature request, and watch the python split wars happen all over again >:-}

• jowea 3y ago
  I genuinely wonder if this issue would cause a fork. At least a long term maintenance that keeps the GIL.
  • kzrdude 3y ago
    Python is closer to C than we all like to imagine, in more than one way. Lots of access to low-level libraries. Long history of writing modules in C. And little in actual memory safety protection more than relying on programmers to please not write bugs in their C or ctypes code. Philosophically, Python is close to C in the sense that low-abstraction interfaces to system functionality (file descriptors, memory) exist. Numpy allows access to uninitalized memory and you can manipulate how numpy uses memory (mmap, shared memory, sharing memory between objects). Ctypes allows access to malloc and dereferencing dangling pointers. This is not exactly normal Python, but it's inside the realm of the possible in Python. All of this makes me worried that the challenge of "free threading" is quite large. I wonder if the subinterpreters solution offers a safer route. At least it's not pulling off the GIL band-aid all in one go.
    • formerly_proven 3y ago
      Can’t even call print or logging from signal handlers (that’s UB in Python), despite being bounced off of the VM.
    • kzrdude 3y ago
      On other hand, allowing access to free threading would be a straight-line continuation of this culture: just make that feature available. ("we're writing system code in a high level language.")