On 5 Oct 2021, at 12:40, Petr Viktorin encukou@gmail.com wrote:
On 08. 09. 21 17:21, Victor Stinner wrote:
On Wed, Sep 8, 2021 at 3:49 PM Petr Viktorin encukou@gmail.com wrote:
I converted Py_TYPE() and Py_SIZE() macros to static inline functions in the future Python 3.11. It's a backward incompatible change. For example, "Py_TYPE(obj) = type;" must be replaced with "Py_SET_TYPE(obj, type);".
Why is this needed? Read the issue for the rationale: https://bugs.python.org/issue39573#msg361513 See also: https://www.python.org/dev/peps/pep-0620/
The reason I asked is that this formally needs SC exception to the backwards compatibility policy. I can apply for the exception if you don't want to, but I'd like to give some good arguments for it -- and while I agree with most of what's in these documents, I don't think making this particular change now is good.
To summarize how I feel:
- CPython and third-party projects can port to Py_SET_TYPE now.
- Experiments (like tagged pointers) can be tried with only the ported third-party projects.
A problem with Py_SET_TYPE is that it has no way to report errors, which means it is not compatible with tagged pointers.
IMHO future proof API should always have a way to report errors (for example through a return value), even if the current CPython implementation will always succed.
Btw. I don’t particularly mind minor changes like the introduction of Py_SET_TYPE because adopting these is can almost be done mechanically.
Larger API changes, like the (needed) deprecation and later removal of the old buffer API, can be more problematic because they can require significant work.
Ronald —
Twitter / micro.blog: @ronaldoussoren Blog: https://blog.ronaldoussoren.net/