Is structures of builtin types are guarded by deprecation process? (original) (raw)

April 16, 2022, 11:58am 1

I added Py_DEPRECATED(3.11) to PyBytesObject.ob_shash because I wanted to remove it in 3.13.
But deprecating it is more difficult than removing it for numpy developer. They asked to provide a clean way to avoid deprecation warning.
(Deprecate ob_shash in BytesObject · Issue #91020 · python/cpython · GitHub)

Before adding another API for numpy and other libraries subclassing bytes object but don’t want to call bytes.__new__(), I want to make it clear that we really need to add Py_DEPRECATED to structure members.

We change the implementation of builtin types some time.
For example, there is discussion about changing long object (More efficient implementation of integers · Discussion #147 · faster-cpython/ideas · GitHub).

Do we need to add Py_DEPRECATED and wait two releases before changing the structure of builtin objects?

vstinner (Victor Stinner) April 19, 2022, 6:56am 2

It would be great to remove PyUnicodeObject structure members from the public C API to be able to change the implementation details tomorrow (ex: experiment UTF-8) or ease interoperability with other Python implementations (PyPy uses UTF-8, not PEP 393).

vstinner (Victor Stinner) April 19, 2022, 6:57am 3

My PEP 620 covers the general topic of making structures opaque in Python long term: PEP 620 – Hide implementation details from the C API | peps.python.org The new HPy API basically make all structures opaque.