Skip to content

GIL Refs API Removal - Tracking Issue #3960

Closed
@davidhewitt

Description

@davidhewitt

The main steps remaining to remove GIL Refs:

For 0.22

In 0.22 the gil-refs feature will continue to be available, but with two major differences from 0.21. The deprecation warnings will be unconditional and the APIs will be gated behind the feature.

For 0.23

  • Mass deletion of deprecated APIs🚀
  • For _bound variants like PyTuple::new_bound:
    • Add plain variants like PyTuple::new again.
    • Add deprecation markers on PyTuple::new_bound to nudge users to the plain versions again.

Optional polishing tasks from #3684

  • Split PyModuleMethods to move functionality related to creating / building new modules into a PyModuleBuilder? implement PyModuleMethods #3703 (comment)
  • Generic IntoPy<Py<T>> for Bound<'_, T>? implement PyTupleMethods #3681 (comment)
  • Should Borrowed<'py, 'py, T>::into_gil_ref become public API as well?
  • FromPyObject could gain a lifetime 'a to its argument &'a Bound<'py>, allowing:
    • downcasting the Bound to allow impl FromPyObject for &Bound
    • impl FromPyObject<'a, '_> for &'a str without the pool; as the lifetime of the string borrow depends on the lifetime of the input, not the GIL lifetime
    • would allow PyRef and PyRefMut to store &'a Bound<'py, T> (or borrowed) and avoid reference count overhead
  • Update py.None(), py.Ellipsis() and py.NotImplemented() to return Borrowed<'py, 'py, PyNone> (etc.)
  • It would be nice to accept #[pyo3(from_py_with = "PyAnyMethods::len")] (and similar)

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions