On Wed, Nov 24, 2021 at 10:59 AM Petr Viktorin <encu...@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-functions > 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 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. 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. > 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). Victor -- Night gathers, and now my watch begins. It shall not end until my death. _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/LYDQ2TDTPYTDIIFLTUMNPOITCOTHZOKA/ Code of Conduct: http://python.org/psf/codeofconduct/
