On 09. 02. 22 21:41, Gregory P. Smith wrote:
On Wed, Feb 9, 2022 at 8:54 AM Victor Stinner <vstin...@python.org
[...]
Two differing examples from that PR 31221:
Hold off as unsafe for now: Macros that do things like
(PyWhateverObject*)(op) such as PyUnicode_CHECK_INTERNED(op) should not
have the casting part of macros replaced yet. Doing so could result in a
warning or failure at -Werror compile time if someone was not using a
PyObject*. Code is /supposed/ to, but the cast means anyone could've
used PyUnicodeObject or whatnot itself. Perhaps use a hybrid approach
when feasible similar to:
#define PyUnicode_CHECK_INTERNED(op)
_PyUnicode_CHECK_INTERNED((PyASCIIObject *)(op))
That should make it safe. And I believe you do mention this technique
as something to be used in the PEP.
That technique is mentioned in the PEP, but it looks like we just found
a better way to do it than what the PEP suggests: the macro and the
function can have the same namea
Are there any downsides to that? We don't know of any so far. Is it a
widely used trick in some other codebases? Should we try to find to
people who use it regularly and ask what to do and what to watch out for?
If we just approved the PEP, a lot of the macros would probably get
converted to what the PEP suggests. With a bit more time and discussion,
we can arrive at a better solution.
This is a large change across the whole codebase. It won't be easy to
fix it up later. It won't be easy to revert it if things go wrong.
IMO this is a case where "never is better than *right* now". But it
doesn't need to be "never".
_______________________________________________
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/RSNDG7NTQZYPR6ZDHDNZPY7JONXBLVUF/
Code of Conduct: http://python.org/psf/codeofconduct/
