
On 24. 11. 21 15:32, Victor Stinner wrote:
On Wed, Nov 24, 2021 at 2:18 PM Petr Viktorin <encukou@gmail.com> wrote:
The "Backwards Compatibility" section is very small. Can you give a list of macros which lost/will lose "return values"?
https://bugs.python.org/issue45476 lists many of them. See also: https://github.com/python/cpython/pull/28976
Also, this PR is about preventing the use of some macros as l-values, which you say is out of scope for the PEP. I'm connfused.
Oh right, now I'm also confused :-) I forgot about the details.
"Py_TYPE(obj) = new_type;" was used in 3rd party C extensions when defining static types to work around linker issues on Windows. Changing Py_TYPE() to disallow using it as an l-value is an incompatible change.
From what I saw in bpo-45476, the functions that I propose to change are not used as l-value. Technically, it's an incompatible change. In practice, it should not impact any 3rd party project.
For example, PyFloat_AS_DOUBLE() is used to read a float value (ex: "double x = PyFloat_AS_DOUBLE(obj);"), but not to set a float value (ex: "PyFloat_AS_DOUBLE(obj) = 1.0;").
Ok, I should clarify that in the PEP.
Yes. *Each* incompatible change should be listed, even if you believe it won't affect any project. The PEP reader should be allowed to judge if your assumptions are correct. e.g. I've seen projects actually use "Py_TYPE(obj) = new_type;" to change an object's type after it was given to Python code. It would be great to document why that's wrong *and* what to do instead, both in the PEP that introduced the change and in the "What's New" entry.
Wait, so this PEP is about converting macros to functions, but not about converting Py_SIZE to a function? I'm confused. Why is Py_SIZE listed in the PEP?
Py_SIZE() is already converted to a static inline function. Later, it can be converted to a regular function if it makes sense.
It's listed in the PEP to show macros which are already converted, to help to estimate how many 3rd party applications would be affected by the PEP.
Is such an estimate available?
Py_REFCNT(), Py_TYPE() and Py_SIZE() are special because they were used as l-value on purpose. As far as I know, they were the only 3 macros used as l-value, no?
Who knows? If there's a list of what to change, someone can go through it and answer this for each macro.