Repository navigation
C API: Add replacements for PyObject_HasAttr() etc #108511
Description
Activity
In the PR you propose new names of the form
PyMapping_HasKeyWithError(etc.). That's a rather long name. Does this follow a convention we use elsewhere in the C API? (I understand that the "ideal" name is already taken by a similar function that has a design flaw.)There is a single precedence: the
PyDict_GetItem()/PyDict_GetItemWithError()pair. AddingPyObject_HasAttrWithError()andPyMapping_HasKeyWithError()will make it an established convention.I asked about names in https://discuss.python.org/t/replacements-for-pymapping-haskey-pymapping-haskeystring-pyobject-hasattr-and-pyobject-hasattrstring/32589, and
WithErrorlooks like the least bad suffix.We can also use
PyMapping_Contains(), similar to the existingPyDict_Contains(). But I do not know alternative name toPyObject_HasAttrWithError().Other approach was used for the
PyArg_Parse*()functions. The original functions had a flaw (the worked with size asintinstead ofPy_ssize_t), so new functions like_PyArg_ParseTuple_SizeT()was introduced, and then defines conditionally redefinedPyArg_ParseTupleto_PyArg_ParseTuple_SizeT. I don't like how it ended -- eventually ABI compatibility was broken. In 3.12PyArg_ParseTupleraises an exception, and in 3.13 it is the same as_PyArg_ParseTuple_SizeT(crashing or working incorrectly if the caller code was not fixed). So if we take this approach, we can get a user code which skipped Python versions and was not changed to handle errors returned by newPyObject_HasAttr(). It will just take more time.Okay, I think just introducing the new names now seems the right thing, and it looks like
WithErroris the best suffix we can think of. I don't like the macro juggling approach (though in the past I might have) so let's just live with the new and old API together, and encourage users by only peaceful means to update their code.I didn't like when
define PY_SSIZE_T_CLEANwas added. Most C extensions had to add it. Not all of them. It's hard to know if a C extension was modernized or not.I didn't like when it was removed: is it ok to remove if you keep Python 3.6 support? Is it going to break stuffs?
IMO this dark macro magic is hard to understand as an user.
Reacted by Eric Werner- added a commit that references this issue
on Sep 17, 2023
Feature or enhancement
Has this already been discussed elsewhere?
No response given
Links to previous discussion of this feature:
#75753
#106672
Proposal:
Functions
PyDict_GetItem(),PyDict_GetItemString(),PyMapping_HasKey(),PyMapping_HasKeyString(),PyObject_HasAttr(),PyObject_HasAttrString()andPySys_GetObject()have a flaw -- they clear any error raised inside the function, including important and critical errors. They cannot be fixed, because the user code which use them do not handle errors. There are replacements free from this flaw forPyDict_GetItem()(PyDict_GetItemWithError()andPyDict_GetItemRef()) and, in some applications, toPyDict_GetItemString()(PyDict_GetItemRefString()).We need new functions similar to
PyMapping_HasKey(),PyMapping_HasKeyString(),PyObject_HasAttr(),PyObject_HasAttrString()which return three-state value (1- yes,0-- no, and-1--error). What should be their names? Add theWithErrorsuffix? Add theExsufix? Add the2suffix?Linked PRs