On 24. 11. 21 13:20, Victor Stinner wrote:
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 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?
_______________________________________________
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/K52XIAU4WBVSJBAXZLC4EOP3BBCILLNC/
Code of Conduct: http://python.org/psf/codeofconduct/
