GV

GeezerVison

The World Wide Web, restored to 800 pixels of glory.

Home|About|Gaming cabinet|Archives|How it works|Starter sites

On this site

  • Sign in
  • ActionsCI/CD and automation
  • CodespacesCloud development environments
  • All Features
  • Documentation
  • Training
  • Certifications
  • Build with Copilot
  • Customize Copilot
  • Integrations
  • Trending repos
  • GitHub Sponsors
  • Developer articles
  • Enterprises

This view

  • Original page
  • New address

GeezerVison is showing github.com — gh-108511: Add C API functions which do not silently ignore errors by serhiy-storchaka · Pull Request #109025 · python/cpython

Conversation

@serhiy-storchaka

@serhiy-storchaka serhiy-storchaka commented Sep 6, 2023 •
edited by github-actions Bot
Loading

Uh oh!

There was an error while loading. Please reload this page.

Copy link
Copy Markdown
Member

Add the following functions:

  • PyObject_HasAttrWithError()
  • PyObject_HasAttrStringWithError()
  • PyMapping_HasKeyWithError()
  • PyMapping_HasKeyStringWithError()
  • Issue: C API: Add replacements for PyObject_HasAttr() etc #108511

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

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

All reactions
@serhiy-storchaka
pythongh-108511: Add C API functions which do not silently ignore errors
ae6e789
Add the following functions:

* PyObject_HasAttrWithError()
* PyObject_HasAttrStringWithError()
* PyMapping_HasKeyWithError()
* PyMapping_HasKeyStringWithError()
@serhiy-storchaka serhiy-storchaka added type-feature A feature request or enhancement topic-C-API labels Sep 6, 2023
@serhiy-storchaka
serhiy-storchaka requested review from kumaraditya303, markshannon and methane as code owners September 6, 2023 20:13
@bedevere-bot bedevere-bot added the awaiting core review label Sep 6, 2023
@bedevere-bot bedevere-bot mentioned this pull request Sep 6, 2023
C API: Add replacements for PyObject_HasAttr() etc #108511
Closed
@serhiy-storchaka
regen-limited-abi
7bcdfad
@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
methane
methane approved these changes Sep 12, 2023
View reviewed changes
@serhiy-storchaka
serhiy-storchaka merged commit add16f1 into python:main Sep 17, 2023
@bedevere-app bedevere-app Bot removed the awaiting core review label Sep 17, 2023
@serhiy-storchaka
serhiy-storchaka deleted the PyObject_HasAttrWithError-PyMapping_HasKeyWithError branch September 17, 2023 11:23
@bedevere-bot

bedevere-bot commented Sep 17, 2023

Copy link
Copy Markdown

⚠️⚠️⚠️ 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'")]
All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

@bedevere-bot

bedevere-bot commented Sep 17, 2023

Copy link
Copy Markdown

⚠️⚠️⚠️ 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]
All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

@bedevere-bot

bedevere-bot commented Sep 17, 2023

Copy link
Copy Markdown

⚠️⚠️⚠️ 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']
All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

@bedevere-bot

bedevere-bot commented Sep 17, 2023

Copy link
Copy Markdown

⚠️⚠️⚠️ 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
All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

@bedevere-bot

bedevere-bot commented Sep 17, 2023

Copy link
Copy Markdown

⚠️⚠️⚠️ 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
All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

@bedevere-bot

bedevere-bot commented Sep 17, 2023

Copy link
Copy Markdown

⚠️⚠️⚠️ 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
All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

@bedevere-bot

bedevere-bot commented Sep 17, 2023

Copy link
Copy Markdown

⚠️⚠️⚠️ 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
All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

@vstinner

vstinner commented Sep 18, 2023

Copy link
Copy Markdown
Member

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

All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

csm10495 pushed a commit to csm10495/cpython that referenced this pull request Sep 28, 2023
@serhiy-storchaka @csm10495
pythongh-108511: Add C API functions which do not silently ignore err…
b14d608
…ors (pythonGH-109025)

Add the following functions:

* PyObject_HasAttrWithError()
* PyObject_HasAttrStringWithError()
* PyMapping_HasKeyWithError()
* PyMapping_HasKeyStringWithError()
scoder
scoder reviewed Oct 15, 2023
View reviewed changes
Comment thread Doc/c-api/mapping.rst

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``.

@scoder scoder Oct 15, 2023

Copy link
Copy Markdown
Contributor

There was a problem hiding this comment.

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.

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

All reactions

@vstinner vstinner Oct 16, 2023

Copy link
Copy Markdown
Member

There was a problem hiding this comment.

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 :-)

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

All reactions
Comment thread Doc/c-api/object.rst

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``.

@scoder scoder Oct 15, 2023

Copy link
Copy Markdown
Contributor

There was a problem hiding this comment.

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.

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

encukou reacted with thumbs up emoji
All reactions
  • 👍 1 reaction
gmarkall added a commit to gmarkall/numba-cuda that referenced this pull request May 19, 2025
@gmarkall
Add CUDA simulator test workflow
6226549
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
@gmarkall
Add CUDA simulator test workflow
2bb08b2
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
@gmarkall
Add CUDA simulator test workflow
02c45b1
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
@gmarkall
Add CUDA simulator test workflow
af8eec9
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
@gmarkall
Add CUDA simulator test workflow
26fd849
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
@gmarkall
Add CUDA simulator test workflow
695b590
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
@gmarkall
Add CUDA simulator test workflow
5de9031
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
@gmarkall
Add CUDA simulator test workflow
9ebb135
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
@gmarkall
Add CUDA simulator test workflow
e48c69b
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
@gmarkall
Add CUDA simulator test workflow
c3e0799
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
@coderabbitai coderabbitai Bot mentioned this pull request Jun 25, 2026
Add more mapping functions to c-api RustPython/RustPython#8169
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@vstinner vstinner vstinner left review comments
@scoder scoder scoder left review comments
@methane methane methane approved these changes
@markshannon markshannon Awaiting requested review from markshannon markshannon is a code owner
@encukou encukou Awaiting requested review from encukou encukou is a code owner

Uh oh!

There was an error while loading. Please reload this page.

Assignees

No one assigned

Labels

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

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

Uh oh!

There was an error while loading. Please reload this page.

5 participants

@serhiy-storchaka @bedevere-bot @vstinner @methane @scoder
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
You are visitor 01402503 — GeezerVison does not store the pages you look up.
Best viewed with Netscape Navigator 4.7 or Internet Explorer 6 at 800×600. No cookies required.