Closed glevco closed 1 month ago
@mejrs
Why? I don't have a strong opinion either way, but slightly prefer
PyModule::import
.
Since Python::import
was used in the implementation of get_or_try_init_type_ref
, I assumed it was preferable. Also, it pairs nicely with the other entries in this section of the guide, as they recommend other "global" functions such as Python::eval
and Python::run
. What do you think?
I prefer PyModule::import
too, I think it's nicer to think of that as a "constructor" for the PyModule
type.
What do you think?
From a documentation perspective I would prefer that people visit PyModule::import
over Python::import
. Python
has a lot of not module related api, and its page is a lot bigger.
Also, using "constructor" syntax also makes it clear that when they use it, they're getting a module (rather than something arbitrary like from foo import bar
might do).
@davidhewitt @mejrs Fair enough, I reverted the guide back to PyModule::import
in https://github.com/PyO3/pyo3/pull/4542/commits/79568f6c267d8973504eb94b19ae0f32a92d066c. I also changed the method name to GILOnceCell::import
and made its impl generic for PyTypeCheck
, as discussed above. I updated the PR description accordingly.
Resolves https://github.com/PyO3/pyo3/issues/4516.
GILOnceCell::get_or_try_init_type_ref
toGILOnceCell::import
and make it public API, adding an example for it.GILOnceCell::import
.Python::eval_bound
(which is deprecated) toPython::eval
.Python::run_bound
(which is deprecated) toPython::run
, also adding missing link.