C API: Add replacements for PyObject_HasAttr() etc #108511
Comments
serhiy-storchaka
added
type-feature
Add the following functions: * PyObject_HasAttrWithError() * PyObject_HasAttrStringWithError() * PyMapping_HasKeyWithError() * PyMapping_HasKeyStringWithError()
|
In the PR you propose new names of the form |
|
There is a single precedence: the I asked about names in https://discuss.python.org/t/replacements-for-pymapping-haskey-pymapping-haskeystring-pyobject-hasattr-and-pyobject-hasattrstring/32589, and We can also use Other approach was used for the |
|
Okay, I think just introducing the new names now seems the right thing, and it looks like |
|
I didn't like when 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. |
…H-109025) Add the following functions: * PyObject_HasAttrWithError() * PyObject_HasAttrStringWithError() * PyMapping_HasKeyWithError() * PyMapping_HasKeyStringWithError()
…ors (pythonGH-109025) Add the following functions: * PyObject_HasAttrWithError() * PyObject_HasAttrStringWithError() * PyMapping_HasKeyWithError() * PyMapping_HasKeyStringWithError()
The simulator needs to be tested with Python 3.12 - it presently does
not fully work on Python 3.13 due to the change in behaviour for
`PyObject_HasAttr()` to no longer silently ignore all errors as it did
previously.
Numba's typecode fingerprinting calls something which is approximately
`PyObject_HasAttr("_numba_type_")` on NumPy arrays during some execution
paths of the simulator, which causes NumPy to raise `ValueError("no
field of name _numba_type_")`. Since Python 3.13 this causes masses of
warnings to be raised that flood the output.
References:
- Python 3.12 `PyObject_HasAttr()`:
https://docs.python.org/3.12/c-api/object.html#c.PyObject_HasAttr
> "Exceptions that occur when this calls __getattr__() and
> __getattribute__() methods are silently ignored."
- Python 3.13 `PyObject_HasAttr()`:
https://docs.python.org/3.13/c-api/object.html#c.PyObject_HasAttr
> "Exceptions that occur when this calls __getattr__() and
> __getattribute__() methods aren’t propagated, but instead given to
> sys.unraisablehook(). For proper error handling, use
> PyObject_HasAttrWithError(), ..."
- CPython commit adding the recommended functions:
python/cpython#109025
- CPython issue: python/cpython#108511
The simulator needs to be tested with Python 3.12 - it presently does
not fully work on Python 3.13 due to the change in behaviour for
`PyObject_HasAttr()` to no longer silently ignore all errors as it did
previously.
Numba's typecode fingerprinting calls something which is approximately
`PyObject_HasAttr("_numba_type_")` on NumPy arrays during some execution
paths of the simulator, which causes NumPy to raise `ValueError("no
field of name _numba_type_")`. Since Python 3.13 this causes masses of
warnings to be raised that flood the output.
References:
- Python 3.12 `PyObject_HasAttr()`:
https://docs.python.org/3.12/c-api/object.html#c.PyObject_HasAttr
> "Exceptions that occur when this calls __getattr__() and
> __getattribute__() methods are silently ignored."
- Python 3.13 `PyObject_HasAttr()`:
https://docs.python.org/3.13/c-api/object.html#c.PyObject_HasAttr
> "Exceptions that occur when this calls __getattr__() and
> __getattribute__() methods aren’t propagated, but instead given to
> sys.unraisablehook(). For proper error handling, use
> PyObject_HasAttrWithError(), ..."
- CPython commit adding the recommended functions:
python/cpython#109025
- CPython issue: python/cpython#108511
The simulator needs to be tested with Python 3.12 - it presently does
not fully work on Python 3.13 due to the change in behaviour for
`PyObject_HasAttr()` to no longer silently ignore all errors as it did
previously.
Numba's typecode fingerprinting calls something which is approximately
`PyObject_HasAttr("_numba_type_")` on NumPy arrays during some execution
paths of the simulator, which causes NumPy to raise `ValueError("no
field of name _numba_type_")`. Since Python 3.13 this causes masses of
warnings to be raised that flood the output.
References:
- Python 3.12 `PyObject_HasAttr()`:
https://docs.python.org/3.12/c-api/object.html#c.PyObject_HasAttr
> "Exceptions that occur when this calls __getattr__() and
> __getattribute__() methods are silently ignored."
- Python 3.13 `PyObject_HasAttr()`:
https://docs.python.org/3.13/c-api/object.html#c.PyObject_HasAttr
> "Exceptions that occur when this calls __getattr__() and
> __getattribute__() methods aren’t propagated, but instead given to
> sys.unraisablehook(). For proper error handling, use
> PyObject_HasAttrWithError(), ..."
- CPython commit adding the recommended functions:
python/cpython#109025
- CPython issue: python/cpython#108511
The simulator needs to be tested with Python 3.12 - it presently does
not fully work on Python 3.13 due to the change in behaviour for
`PyObject_HasAttr()` to no longer silently ignore all errors as it did
previously.
Numba's typecode fingerprinting calls something which is approximately
`PyObject_HasAttr("_numba_type_")` on NumPy arrays during some execution
paths of the simulator, which causes NumPy to raise `ValueError("no
field of name _numba_type_")`. Since Python 3.13 this causes masses of
warnings to be raised that flood the output.
References:
- Python 3.12 `PyObject_HasAttr()`:
https://docs.python.org/3.12/c-api/object.html#c.PyObject_HasAttr
> "Exceptions that occur when this calls __getattr__() and
> __getattribute__() methods are silently ignored."
- Python 3.13 `PyObject_HasAttr()`:
https://docs.python.org/3.13/c-api/object.html#c.PyObject_HasAttr
> "Exceptions that occur when this calls __getattr__() and
> __getattribute__() methods aren’t propagated, but instead given to
> sys.unraisablehook(). For proper error handling, use
> PyObject_HasAttrWithError(), ..."
- CPython commit adding the recommended functions:
python/cpython#109025
- CPython issue: python/cpython#108511
The simulator needs to be tested with Python 3.12 - it presently does
not fully work on Python 3.13 due to the change in behaviour for
`PyObject_HasAttr()` to no longer silently ignore all errors as it did
previously.
Numba's typecode fingerprinting calls something which is approximately
`PyObject_HasAttr("_numba_type_")` on NumPy arrays during some execution
paths of the simulator, which causes NumPy to raise `ValueError("no
field of name _numba_type_")`. Since Python 3.13 this causes masses of
warnings to be raised that flood the output.
References:
- Python 3.12 `PyObject_HasAttr()`:
https://docs.python.org/3.12/c-api/object.html#c.PyObject_HasAttr
> "Exceptions that occur when this calls __getattr__() and
> __getattribute__() methods are silently ignored."
- Python 3.13 `PyObject_HasAttr()`:
https://docs.python.org/3.13/c-api/object.html#c.PyObject_HasAttr
> "Exceptions that occur when this calls __getattr__() and
> __getattribute__() methods aren’t propagated, but instead given to
> sys.unraisablehook(). For proper error handling, use
> PyObject_HasAttrWithError(), ..."
- CPython commit adding the recommended functions:
python/cpython#109025
- CPython issue: python/cpython#108511
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
The text was updated successfully, but these errors were encountered: