There are different meanings of thread safe and of “safety” in general. Python can have thread-safety issues but is in general a memory-safe language. The purpose of the GIL is to provide that memory safety. Python programmers are not generally used to segfaults or totally undefined behaviour which is the kind of thread-safe that applies when talking about extension modules and Py_MOD_GIL_NOT_USED.
The situation now is that with python-flint you can in one thread set an element of a matrix:
M[0,0] = 2
In another thread you can compute the determinant of the matrix:
d = M.det()
Currently the GIL ensures that these two operations take place one after another although the order is undefined. This means that you might get d = 10 or you might get d = 20 but exactly one of those possibilities will occur and Python won’t crash or anything.
Without the GIL what can happen is that M[0,0] = 2 might trigger a call to realloc under the hood and then the code in the det function finds itself wandering around deallocated memory. This is now completely undefined behaviour: you can get pure garbage bytes from memory or you can get segfaults occurring either immediately or possibly much later as a result of memory corruption. It is impossible for me to give any real constraints on exactly what sort of bad things may or may not result from this although usually the outcome is either that it happens to work fine or that you get a segfault.
There absolutely will be an expectation that extension module authors do not generally allow that kind of unsafe behaviour regardless of whether the user is doing something that clearly involves data races. For now though free-threading is experimental and so I am happy to put out the wheels and let people try them even if I know that they might crash with segfaults. I also feel reassured that this is a reasonable approach since it is mentioned in the only document I have seen that provides meaningful advice for what extension module authors should do.
Does simply setting Py_MOD_GIL_NOT_USED and then uploading the wheels qualify for a “free-threading supported badge” even if it is expected that some multithreaded usage can result in completely undefined behaviour?