Recommended priority for Obtaining a Python Token: style or substance

[Michael-J-Ward]

I see the recommend priority for ways to acquire a Python<'py> token.

Is this recommended priority strictly a convention (style) issue? Or are there correctness / performance implications between the choices?

The following are the recommended ways to obtain a [Python] token, in order of preference:

1. In a function or method annotated with #[pyfunction] or #[pymethods] you can declare it as a parameter, and PyO3 will pass in the token when Python code calls it.
2. If you already have something with a lifetime bound to the GIL, such as &[PyAny], you can use its .py() method to get a token.
3. When you need to acquire the GIL yourself, such as when calling Python code from Rust, you should call [Python::with_gil] to do that and pass your code as a closure to it.

In particular, I'm asking because adding an extra python argument to a method that already accepts Bound<'_, T> feels superfluous / clutter.

[davidhewitt]

Great question. I have come to the same preference as you that using .py() to get it is tidier (and works in functions that aren't #[pyfunction] or #[pymethods], so is more universally applicable.

I've just opened #4274 to switch the order.

Indeed both of the first two options are zero-cost, so I've also added that as a clarification.