Skip to content

Conversation

serhiy-storchaka
Copy link
Member

@serhiy-storchaka serhiy-storchaka commented Sep 6, 2023

Add the following functions:

  • PyObject_HasAttrWithError()
  • PyObject_HasAttrStringWithError()
  • PyMapping_HasKeyWithError()
  • PyMapping_HasKeyStringWithError()

📚 Documentation preview 📚: https://cpython-previews--109025.org.readthedocs.build/

Add the following functions:

* PyObject_HasAttrWithError()
* PyObject_HasAttrStringWithError()
* PyMapping_HasKeyWithError()
* PyMapping_HasKeyStringWithError()
@serhiy-storchaka serhiy-storchaka requested review from a team and encukou as code owners September 6, 2023 20:45
@kumaraditya303 kumaraditya303 removed their request for review September 12, 2023 17:46
@serhiy-storchaka serhiy-storchaka merged commit add16f1 into python:main Sep 17, 2023
@serhiy-storchaka serhiy-storchaka deleted the PyObject_HasAttrWithError-PyMapping_HasKeyWithError branch September 17, 2023 11:23
@bedevere-bot
Copy link

⚠️⚠️⚠️ Buildbot failure ⚠️⚠️⚠️

Hi! The buildbot s390x RHEL8 3.x has failed when building commit add16f1.

What do you need to do:

  1. Don't panic.
  2. Check the buildbot page in the devguide if you don't know what the buildbots are or how they work.
  3. Go to the page of the buildbot that failed (https://buildbot.python.org/all/#builders/509/builds/4924) and take a look at the build logs.
  4. Check if the failure is related to this commit (add16f1) or if it is a false positive.
  5. If the failure is related to this commit, please, reflect that on the issue and make a new Pull Request with a fix.

You can take a look at the buildbot page here:

https://buildbot.python.org/all/#builders/509/builds/4924

Failed tests:

  • test_tools

Failed subtests:

  • test_freeze_simple_script - test.test_tools.test_freeze.TestFreeze.test_freeze_simple_script

Summary of the results of the build (if available):

==

Click to see traceback logs
Traceback (most recent call last):
  File "/home/dje/cpython-buildarea/3.x.edelsohn-rhel8-z/build/Lib/test/test_tools/test_freeze.py", line 28, in test_freeze_simple_script
    outdir, scriptfile, python = helper.prepare(script, outdir)
                                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/dje/cpython-buildarea/3.x.edelsohn-rhel8-z/build/Tools/freeze/test/freeze.py", line 146, in prepare
    copy_source_tree(srcdir, SRCDIR)
  File "/home/dje/cpython-buildarea/3.x.edelsohn-rhel8-z/build/Tools/freeze/test/freeze.py", line 95, in copy_source_tree
    shutil.copytree(oldroot, newroot, ignore=ignore_non_src)
  File "/home/dje/cpython-buildarea/3.x.edelsohn-rhel8-z/build/Lib/shutil.py", line 588, in copytree
    return _copytree(entries=entries, src=src, dst=dst, symlinks=symlinks,
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/dje/cpython-buildarea/3.x.edelsohn-rhel8-z/build/Lib/shutil.py", line 542, in _copytree
    raise Error(errors)
shutil.Error: [('/home/dje/cpython-buildarea/3.x.edelsohn-rhel8-z/build/build/test_python_2730921æ/tmpiuadha4u', '/tmp/test_python_yi9eetzr/tmp8zxr_xn3/cpython/build/test_python_2730921æ/tmpiuadha4u', "[Errno 2] No such file or directory: '/home/dje/cpython-buildarea/3.x.edelsohn-rhel8-z/build/build/test_python_2730921æ/tmpiuadha4u'")]

@bedevere-bot
Copy link

⚠️⚠️⚠️ Buildbot failure ⚠️⚠️⚠️

Hi! The buildbot aarch64 Debian Clang LTO + PGO 3.x has failed when building commit add16f1.

What do you need to do:

  1. Don't panic.
  2. Check the buildbot page in the devguide if you don't know what the buildbots are or how they work.
  3. Go to the page of the buildbot that failed (https://buildbot.python.org/all/#builders/1084/builds/2016) and take a look at the build logs.
  4. Check if the failure is related to this commit (add16f1) or if it is a false positive.
  5. If the failure is related to this commit, please, reflect that on the issue and make a new Pull Request with a fix.

You can take a look at the buildbot page here:

https://buildbot.python.org/all/#builders/1084/builds/2016

Failed tests:

  • test.test_multiprocessing_fork.test_misc

Failed subtests:

  • test_nested_startmethod - test.test_multiprocessing_fork.test_misc.TestStartMethod.test_nested_startmethod

Summary of the results of the build (if available):

==

Click to see traceback logs
Traceback (most recent call last):
  File "/var/lib/buildbot/workers/arm64-clang/3.x.gps-arm64-debian.clang.lto-pgo/build/Lib/test/_test_multiprocessing.py", line 5475, in test_nested_startmethod
    self.assertEqual(results, [2, 1])
AssertionError: Lists differ: [1, 2] != [2, 1]

@bedevere-bot
Copy link

⚠️⚠️⚠️ Buildbot failure ⚠️⚠️⚠️

Hi! The buildbot s390x RHEL7 LTO + PGO 3.x has failed when building commit add16f1.

What do you need to do:

  1. Don't panic.
  2. Check the buildbot page in the devguide if you don't know what the buildbots are or how they work.
  3. Go to the page of the buildbot that failed (https://buildbot.python.org/all/#builders/244/builds/5456) and take a look at the build logs.
  4. Check if the failure is related to this commit (add16f1) or if it is a false positive.
  5. If the failure is related to this commit, please, reflect that on the issue and make a new Pull Request with a fix.

You can take a look at the buildbot page here:

https://buildbot.python.org/all/#builders/244/builds/5456

Failed tests:

  • test.test_asyncio.test_subprocess

Failed subtests:

  • test_subprocess_consistent_callbacks - test.test_asyncio.test_subprocess.SubprocessThreadedWatcherTests.test_subprocess_consistent_callbacks

Summary of the results of the build (if available):

==

Click to see traceback logs
Traceback (most recent call last):
  File "/home/dje/cpython-buildarea/3.x.edelsohn-rhel-z.lto-pgo/build/Lib/test/test_asyncio/test_subprocess.py", line 788, in test_subprocess_consistent_callbacks
    self.loop.run_until_complete(main())
  File "/home/dje/cpython-buildarea/3.x.edelsohn-rhel-z.lto-pgo/build/Lib/asyncio/base_events.py", line 664, in run_until_complete
    return future.result()
           ^^^^^^^^^^^^^^^
  File "/home/dje/cpython-buildarea/3.x.edelsohn-rhel-z.lto-pgo/build/Lib/test/test_asyncio/test_subprocess.py", line 780, in main
    self.assertEqual(events, [
AssertionError: Lists differ: [('pi[29 chars]t'), 'pipe_connection_lost', ('pipe_data_recei[57 chars]ted'] != [('pi[29 chars]t'), ('pipe_data_received', 2, b'stderr'), 'pi[57 chars]ted']

@bedevere-bot
Copy link

⚠️⚠️⚠️ Buildbot failure ⚠️⚠️⚠️

Hi! The buildbot AMD64 Debian root 3.x has failed when building commit add16f1.

What do you need to do:

  1. Don't panic.
  2. Check the buildbot page in the devguide if you don't know what the buildbots are or how they work.
  3. Go to the page of the buildbot that failed (https://buildbot.python.org/all/#builders/345/builds/5854) and take a look at the build logs.
  4. Check if the failure is related to this commit (add16f1) or if it is a false positive.
  5. If the failure is related to this commit, please, reflect that on the issue and make a new Pull Request with a fix.

You can take a look at the buildbot page here:

https://buildbot.python.org/all/#builders/345/builds/5854

Failed tests:

  • test_signal

Summary of the results of the build (if available):

==

Click to see traceback logs
Traceback (most recent call last):
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/test/test_signal.py", line 1287, in test_stress_delivery_dependent
    self.assertEqual(len(sigs), N, "Some signals were lost")
AssertionError: 4543 != 10000 : Some signals were lost

@bedevere-bot
Copy link

⚠️⚠️⚠️ Buildbot failure ⚠️⚠️⚠️

Hi! The buildbot PPC64LE RHEL7 LTO + PGO 3.x has failed when building commit add16f1.

What do you need to do:

  1. Don't panic.
  2. Check the buildbot page in the devguide if you don't know what the buildbots are or how they work.
  3. Go to the page of the buildbot that failed (https://buildbot.python.org/all/#builders/43/builds/4241) and take a look at the build logs.
  4. Check if the failure is related to this commit (add16f1) or if it is a false positive.
  5. If the failure is related to this commit, please, reflect that on the issue and make a new Pull Request with a fix.

You can take a look at the buildbot page here:

https://buildbot.python.org/all/#builders/43/builds/4241

Failed tests:

  • test.test_asyncio.test_unix_events
  • test.test_multiprocessing_fork.test_misc

Failed subtests:

  • test_fork_signal_handling - test.test_asyncio.test_unix_events.TestFork.test_fork_signal_handling
  • test_nested_startmethod - test.test_multiprocessing_fork.test_misc.TestStartMethod.test_nested_startmethod

Summary of the results of the build (if available):

==

Click to see traceback logs
Traceback (most recent call last):
  File "/home/buildbot/buildarea/3.x.cstratak-RHEL7-ppc64le.lto-pgo/build/Lib/test/_test_multiprocessing.py", line 5475, in test_nested_startmethod
    self.assertEqual(results, [2, 1])
AssertionError: Lists differ: [1, 2] != [2, 1]


Traceback (most recent call last):
  File "/home/buildbot/buildarea/3.x.cstratak-RHEL7-ppc64le.lto-pgo/build/Lib/unittest/async_case.py", line 90, in _callTestMethod
    if self._callMaybeAsync(method) is not None:
       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/buildbot/buildarea/3.x.cstratak-RHEL7-ppc64le.lto-pgo/build/Lib/unittest/async_case.py", line 117, in _callMaybeAsync
    return self._asyncioTestContext.run(func, *args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/buildbot/buildarea/3.x.cstratak-RHEL7-ppc64le.lto-pgo/build/Lib/test/support/hashlib_helper.py", line 49, in wrapper
    return func_or_class(*args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/buildbot/buildarea/3.x.cstratak-RHEL7-ppc64le.lto-pgo/build/Lib/test/test_asyncio/test_unix_events.py", line 1937, in test_fork_signal_handling
    self.assertTrue(child_handled.is_set())
AssertionError: False is not true

@bedevere-bot
Copy link

⚠️⚠️⚠️ Buildbot failure ⚠️⚠️⚠️

Hi! The buildbot PPC64LE RHEL8 LTO 3.x has failed when building commit add16f1.

What do you need to do:

  1. Don't panic.
  2. Check the buildbot page in the devguide if you don't know what the buildbots are or how they work.
  3. Go to the page of the buildbot that failed (https://buildbot.python.org/all/#builders/361/builds/4062) and take a look at the build logs.
  4. Check if the failure is related to this commit (add16f1) or if it is a false positive.
  5. If the failure is related to this commit, please, reflect that on the issue and make a new Pull Request with a fix.

You can take a look at the buildbot page here:

https://buildbot.python.org/all/#builders/361/builds/4062

Failed tests:

  • test.test_asyncio.test_unix_events
  • test.test_asyncio.test_subprocess

Failed subtests:

  • test_subprocess_consistent_callbacks - test.test_asyncio.test_subprocess.SubprocessThreadedWatcherTests.test_subprocess_consistent_callbacks
  • test_fork_signal_handling - test.test_asyncio.test_unix_events.TestFork.test_fork_signal_handling

Summary of the results of the build (if available):

==

Click to see traceback logs
Traceback (most recent call last):
  File "/home/buildbot/buildarea/3.x.cstratak-RHEL8-ppc64le.lto/build/Lib/test/test_asyncio/test_subprocess.py", line 788, in test_subprocess_consistent_callbacks
    self.loop.run_until_complete(main())
  File "/home/buildbot/buildarea/3.x.cstratak-RHEL8-ppc64le.lto/build/Lib/asyncio/base_events.py", line 664, in run_until_complete
    return future.result()
           ^^^^^^^^^^^^^^^
  File "/home/buildbot/buildarea/3.x.cstratak-RHEL8-ppc64le.lto/build/Lib/test/test_asyncio/test_subprocess.py", line 780, in main
    self.assertEqual(events, [
AssertionError: Lists differ: ['process_exited', ('pipe_data_received', 1, b'stdout')] != [('pipe_data_received', 1, b'stdout'), ('p[95 chars]ted']


Traceback (most recent call last):
  File "/home/buildbot/buildarea/3.x.cstratak-RHEL8-ppc64le.lto/build/Lib/unittest/async_case.py", line 90, in _callTestMethod
    if self._callMaybeAsync(method) is not None:
       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/buildbot/buildarea/3.x.cstratak-RHEL8-ppc64le.lto/build/Lib/unittest/async_case.py", line 117, in _callMaybeAsync
    return self._asyncioTestContext.run(func, *args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/buildbot/buildarea/3.x.cstratak-RHEL8-ppc64le.lto/build/Lib/test/support/hashlib_helper.py", line 49, in wrapper
    return func_or_class(*args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/buildbot/buildarea/3.x.cstratak-RHEL8-ppc64le.lto/build/Lib/test/test_asyncio/test_unix_events.py", line 1937, in test_fork_signal_handling
    self.assertTrue(child_handled.is_set())
AssertionError: False is not true

@bedevere-bot
Copy link

⚠️⚠️⚠️ Buildbot failure ⚠️⚠️⚠️

Hi! The buildbot PPC64LE RHEL7 LTO 3.x has failed when building commit add16f1.

What do you need to do:

  1. Don't panic.
  2. Check the buildbot page in the devguide if you don't know what the buildbots are or how they work.
  3. Go to the page of the buildbot that failed (https://buildbot.python.org/all/#builders/503/builds/3918) and take a look at the build logs.
  4. Check if the failure is related to this commit (add16f1) or if it is a false positive.
  5. If the failure is related to this commit, please, reflect that on the issue and make a new Pull Request with a fix.

You can take a look at the buildbot page here:

https://buildbot.python.org/all/#builders/503/builds/3918

Failed tests:

  • test.test_asyncio.test_unix_events

Failed subtests:

  • test_fork_signal_handling - test.test_asyncio.test_unix_events.TestFork.test_fork_signal_handling

Summary of the results of the build (if available):

==

Click to see traceback logs
Traceback (most recent call last):
  File "/home/buildbot/buildarea/3.x.cstratak-RHEL7-ppc64le.lto/build/Lib/unittest/async_case.py", line 90, in _callTestMethod
    if self._callMaybeAsync(method) is not None:
       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/buildbot/buildarea/3.x.cstratak-RHEL7-ppc64le.lto/build/Lib/unittest/async_case.py", line 117, in _callMaybeAsync
    return self._asyncioTestContext.run(func, *args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/buildbot/buildarea/3.x.cstratak-RHEL7-ppc64le.lto/build/Lib/test/support/hashlib_helper.py", line 49, in wrapper
    return func_or_class(*args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/buildbot/buildarea/3.x.cstratak-RHEL7-ppc64le.lto/build/Lib/test/test_asyncio/test_unix_events.py", line 1937, in test_fork_signal_handling
    self.assertTrue(child_handled.is_set())
AssertionError: False is not true

@vstinner
Copy link
Member

I wrote a first PR to add PyMapping_HasKeyWithError() and PyMapping_HasKeyStringWithError() functions to pythoncapi-compat: python/pythoncapi-compat#73

csm10495 pushed a commit to csm10495/cpython that referenced this pull request Sep 28, 2023
…ors (pythonGH-109025)

Add the following functions:

* PyObject_HasAttrWithError()
* PyObject_HasAttrStringWithError()
* PyMapping_HasKeyWithError()
* PyMapping_HasKeyStringWithError()
Return ``1`` if the mapping object has the key *key* and ``0`` otherwise.
This is equivalent to the Python expression ``key in o``.
On failure, return ``-1``.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Given the relevance of error handling for these new functions, I think the docs should mention explicitly under which conditions users must expect exceptions.

Suggested change
On failure, return ``-1``.
On failure, return ``-1`` with an exception set.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sometimes I write "On error, raise an exception and return -1." Even if in C, technically, it's more "setting" an exception, I like to use Python "raise" semantics in C, it's easy for me to map C/Python this way :-)

Returns ``1`` if *o* has the attribute *attr_name*, and ``0`` otherwise.
This is equivalent to the Python expression ``hasattr(o, attr_name)``.
On failure, return ``-1``.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Given the relevance of error handling for these new functions, I think the docs should mention explicitly under which conditions users must expect exceptions.

Suggested change
On failure, return ``-1``.
On failure, return ``-1`` with an exception set.

gmarkall added a commit to gmarkall/numba-cuda that referenced this pull request May 19, 2025
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
gmarkall added a commit to gmarkall/numba-cuda that referenced this pull request May 19, 2025
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
gmarkall added a commit to gmarkall/numba-cuda that referenced this pull request May 20, 2025
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
gmarkall added a commit to gmarkall/numba-cuda that referenced this pull request May 20, 2025
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
gmarkall added a commit to gmarkall/numba-cuda that referenced this pull request May 20, 2025
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
gmarkall added a commit to gmarkall/numba-cuda that referenced this pull request May 27, 2025
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
gmarkall added a commit to gmarkall/numba-cuda that referenced this pull request May 27, 2025
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
gmarkall added a commit to gmarkall/numba-cuda that referenced this pull request May 27, 2025
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
gmarkall added a commit to gmarkall/numba-cuda that referenced this pull request May 27, 2025
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
gmarkall added a commit to NVIDIA/numba-cuda that referenced this pull request May 27, 2025
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

topic-C-API type-feature A feature request or enhancement

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants