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/

Reply via email to