Uh oh!
There was an error while loading. Please reload this page.
bpo-45476: Disallow using PyFloat_AS_DOUBLE() as l-value - #28976
Conversation
There was a problem hiding this comment.
Typo: "expressing" for "expression"
vstinner
commented
Nov 16, 2021
I wrote PEP 670 https://www.python.org/dev/peps/pep-0670/ to decide what's the best approach to fix https://bugs.python.org/issue45476 |
vstinner
commented
Nov 29, 2021
I rebased the PR and reverted PyBytes_AS_STRING() and PyByteArray_AS_STRING() changes. |
The following "GET" and "AS" functions can no longer be used as l-value (to modify a Python object): * PyByteArray_GET_SIZE() * PyBytes_GET_SIZE() * PyCFunction_GET_CLASS() * PyCFunction_GET_FLAGS() * PyCFunction_GET_FUNCTION() * PyCFunction_GET_SELF() * PyDict_GET_SIZE() * PyFloat_AS_DOUBLE() * PyFunction_GET_ANNOTATIONS() * PyFunction_GET_CLOSURE() * PyFunction_GET_CODE() * PyFunction_GET_DEFAULTS() * PyFunction_GET_GLOBALS() * PyFunction_GET_KW_DEFAULTS() * PyFunction_GET_MODULE() * PyHeapType_GET_MEMBERS() * PyInstanceMethod_GET_FUNCTION() * PyList_GET_SIZE() * PyMemoryView_GET_BASE() * PyMemoryView_GET_BUFFER() * PyMethod_GET_FUNCTION() * PyMethod_GET_SELF() * PySet_GET_SIZE() * PyTuple_GET_SIZE() * PyWeakref_GET_OBJECT() These macros are modified to use the _Py_RVALUE() macro.
vstinner
commented
Nov 30, 2021
@corona10@erlend-aasland@encukou: Would you mind to review this change? It's a C API incompatible change made on purpose to aid detecting bugs in C extensions when the C API is misused. |
encukou
commented
Nov 30, 2021
Is there any deprecation warning for these changes? |
vstinner
commented
Nov 30, 2021
I cannot find any of the 25 macros being used as a l-value in an assignement in the PyPI top 5000 packages. So the risk of breaking 3rd party packages is very low. I searched for the following patterns: Cython-0.29.24.tar.gz is a false positive because of my weak regex: |
vstinner
commented
Nov 30, 2021
No. Which kind of warning do you expect? I am not aware of any technical way to emit a compiler warning when a macro is only used as an l-value, see previous discussion about the Py_TYPE() change: python/steering-council#79 |
vstinner
commented
Nov 30, 2021
@rhettinger: You may want to review the updated PR. I made minor changes since you approved the PR. |
encukou
commented
Nov 30, 2021
The SC decision you linked says:
How does this PR do that? |
vstinner
commented
Nov 30, 2021
Documentation of the modified macros:
The following functions are not documented:
|
vstinner
commented
Nov 30, 2021
For me, using these macros as l-value is an unintentional usage. I don't think that we have to go through a deprecation process for this specific corner case. For "GET" functions, it sounds weird to me to use them to set an object attribute or to modify a Python object. For the |
encukou
commented
Nov 30, 2021
I like to think that the target audience for deprecation messages and "versionchanged" notices is someone who inherited a decades-old legacy project, and is tasked with keeping it usable without knowing much about Python and current best practices. If it works for that audience, it should work for everyone else as well. |
vstinner
commented
Nov 30, 2021
I wrote PEP 674 "Disallow using macros as l-value" for this change: https://python.github.io/peps/pep-0674/ |
The following "GET" and "AS" functions can no longer be used as
l-value (to modify a Python object):
These macros are modified to use the _Py_RVALUE() macro.
https://bugs.python.org/issue45476