Earlier quoted context omitted.
What is better: 1) Saying your package supports free threading, but it isn't safe - ie concurrent mutation can result in corruption and crashes 2) Allowing the package to be loaded into a free threaded Python, which immediately enables the GIL. Concurrent mutation does not result in corruption and crashes because of the GIL. The user doesn't have to maintain two Python installations. They can set the environment vari…
3) Saying your package doesn't support free threading instead of adding a GIL and force the users to stick to regular python.
You aren't forced to use a GIL as I keep stating. You can set an environment variable or a command line flag to Python and the GIL will remain disabled. My package will work just fine if you do that, unless you provide it with data you concurrently modify in which case you can get corruption and crashes.