You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
An idea with the upcoming free threaded Python around the corner.
Maybe instead of Python::with_gil, a future PyO3 API can just be pyo3::with_python. No functional difference except dropping the GIL name as that won't always be relevant.
e.g.
Python::with_gil(|py| /* do stuff */)
becomes just
with_python(|py| /* do stuff */)
Maybe we include with_python in the prelude, maybe we invite users to import it.
The text was updated successfully, but these errors were encountered:
Just throwing some alternatives in the room: Python::in_scope or Python::with_token could also be something if we want to keep it as an (associated) method, but without references to the gil.
I also have recently been thinking about Python::attach (and .allow_threads could become .detach()) - this is the terminology introduced in freethreaded Python - you're either attached to a Python thread state, or the thread state is detached from the interpreter.
I also have recently been thinking about Python::attach (and .allow_threads could become .detach()) - this is the terminology introduced in freethreaded Python
After reading through #4577 I think I quite like these.
An idea with the upcoming free threaded Python around the corner.
Maybe instead of
Python::with_gil
, a future PyO3 API can just bepyo3::with_python
. No functional difference except dropping the GIL name as that won't always be relevant.e.g.
becomes just
Maybe we include
with_python
in the prelude, maybe we invite users to import it.The text was updated successfully, but these errors were encountered: