Skip to content

Conversation

@serhiy-storchaka
Copy link
Member

@serhiy-storchakaserhiy-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-storchakaserhiy-storchaka requested review from a team and encukou as code ownersSeptember 6, 2023 20:45
@kumaraditya303kumaraditya303 removed their request for review September 12, 2023 17:46
@serhiy-storchakaserhiy-storchaka merged commit add16f1 into python:mainSep 17, 2023
@serhiy-storchakaserhiy-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 copytreereturn _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 _copytreeraise 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_startmethodself.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_callbacksself.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_completereturn 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 mainself.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_dependentself.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_startmethodself.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 _callTestMethodifself._callMaybeAsync(method) isnotNone: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/home/buildbot/buildarea/3.x.cstratak-RHEL7-ppc64le.lto-pgo/build/Lib/unittest/async_case.py", line 117, in _callMaybeAsyncreturnself._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 wrapperreturn 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_handlingself.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_callbacksself.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_completereturn future.result() ^^^^^^^^^^^^^^^ File "/home/buildbot/buildarea/3.x.cstratak-RHEL8-ppc64le.lto/build/Lib/test/test_asyncio/test_subprocess.py", line 780, in mainself.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 _callTestMethodifself._callMaybeAsync(method) isnotNone: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/home/buildbot/buildarea/3.x.cstratak-RHEL8-ppc64le.lto/build/Lib/unittest/async_case.py", line 117, in _callMaybeAsyncreturnself._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 wrapperreturn 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_handlingself.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 _callTestMethodifself._callMaybeAsync(method) isnotNone: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/home/buildbot/buildarea/3.x.cstratak-RHEL7-ppc64le.lto/build/Lib/unittest/async_case.py", line 117, in _callMaybeAsyncreturnself._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 wrapperreturn 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_handlingself.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 freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

topic-C-APItype-featureA feature request or enhancement

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants

@serhiy-storchaka@bedevere-bot@vstinner@methane@scoder