
On 24. 11. 21 13:20, Victor Stinner wrote:
On Wed, Nov 24, 2021 at 10:59 AM Petr Viktorin <encukou@gmail.com> wrote:
Are there more macros that are yet to be converted to macros,
I suppose that you mean "to be converted to functions". Yes, there are many, it's the purpose of the PEP.
I didn't provide a list. I would prefer to do it on a case by case basis, as I did previously.
To answer your question: it's basically all macros, especially the ones defined by the public C API, except the ones excluded by the PEP: https://www.python.org/dev/peps/pep-0670/#convert-macros-to-static-inline-fu...
other than the ones in GH-29728?
The purpose of this PR is only to run benchmarks to compare the performance of macros versus static inline functions. The PR title is "Convert static inline to macros": it converts existing Python 3.11 static inline functions back to Python 3.6/3.7 macros. It's basically the opposite of the PEP ;-)
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
Can you put this in the PEP? If things should be evaluated on a case-by-case basiswe should know about the cases. 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.
Can you add the fact that some macros now can't be used as l-values?
If you are are talking about my merged change preventing using Py_TYPE() as an l-value, this is out of the scope of the PEP on purpose.
Py_TYPE(), Py_REFCNT() and Py_SIZE() could be used an l-value in Python 3.9, but it's no longer the case in Python 3.11. Apart of that, I'm not aware of other macros which could be "abused" as l-value.
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?
There are macros which can be "abused" ("used") to access to structure members and object internals. For example, &PyTuple_GET_ITEM(tuple, 0) and &PyList_GET_ITEM(list, 0) can be "abused" to access directly to an array of PyObject* (PyObject** type) and so modify directly a tuple/list. I would like to change that (disallow it), but it's out of the scope of the PEP. See https://bugs.python.org/issue41078 for my previous failed attempt (it broke too many things). But this is more in the scope of the PEP 620 which is a different PEP. >
Are there any other issues that break existing code?
I listed all known backward incompatibles changes in the Backward Compatibility section. I'm not aware of other backward incompatible changes caused by the PEP.
Converting macros to static inline functions or regular functions didn't change the API for the macros already converted, the ones listed in the PEP.
It did for e.g. Py_SIZE, which no longer behaves like in 3.9, nor as it was documented in 3.8: https://docs.python.org/3.8/c-api/structures.html#c.Py_SIZE Yet Py_SIZE is listed in the PEP as "Macros converted to static inline functions", so clearly it is in scope. Same for Py_TYPE. Are there others?
The "Cast to PyObject*" section talks about adding new private functions like _Py_TYPE, which are type-safe, but keeping old names (like Py_TYPE) as macros that do a cast. Could the newly added functions be made public from the start? (They could use names like Py_Type.) This would allow languages that don't have macros to use them directly, and if the non-typesafe macros are ever discouraged/deprecated/removed, this would allow writing compatible code now.
I don't want to increase the size of the C API and so I chose to make the inner function accepting PyObject* private.
I see the addition of an hypothetical Py_Type() function as an increase of the maintenance burden: we would have to maintain it, document it, maybe add it to the limited C API / stable ABI, write tests, etc.
I prefer to restrict the scope of the PEP. If you want to add variants only accepting PyObject*, that's fine, but I suggest to open a separated issue / PEP. Also, it can be discussed on a case by case basic (function per function).
Since functions like _Py_TYPE will need to be maintained as part of the stable ABI, I'd like to do this right from the start. If you don't, can you add this to Rejected ideas? I'm still interested in:
Since this is about converting existing macros (and not writing new ones), can you talk about which of the "macro pitfalls" apply to the macros in CPython that were/will be changed? Is that just a theoretical issue?