Support for free-threaded Python

[alihamdan]

Hello, are there any plans to add support for free-threaded Python?

Free-threading was experimental in Python 3.13 but was stabilized in Python 3.14 which is currently in release-candidate stage. Other popular Python libraries like numpy and pandas support it and cibuildwheel builds free-threaded wheels https://cibuildwheel.pypa.io/en/stable/options/#enable.

Free-threading documentation is here: https://docs.python.org/3.14/howto/free-threading-python.html

[snowman2]

Contributions welcome!

[djhoese]

@snowman2 I can make a PR for this as I'm trying to do it for some of my other libraries, but I haven't kept up to date with the multi-threaded and global context stuff you've done in pyproj. For basic extensions with no global state it is easy enough to define a cython directory:

"freethreading_compatible": True

Either in the setup.py or in a comment at the top of the cython module. This compiler directive basically tells a free-threaded build of python "no I'm good, I know you don't have the GIL" and the interpreter knows it can continue to not worry about the GIL. If not enabled, then Python emits a RuntimeWarning and says that it is re-enabling the GIL because an incompatible extension is being used.

So the question is, is all global state of pyproj locked? I saw the issues related to some weird issues with Transformers being passed between threads, but ignoring those right now, what is your understanding of what thread-safety pyproj has implemented? Do you know of any specific areas or safeties that need to be implemented or "best practice" that needs to be defined for users? For example, "you can pass Transformers between threads but must use a lock to synchronize usage of the transform functionality".

[snowman2]

I cannot think of any blockers at the moment. It may be something to enable and see what happens.