Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

gh-108511: Add C API functions which do not silently ignore errors#109025

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Conversation

serhiy-storchaka
Copy link
Member

@serhiy-storchakaserhiy-storchaka commentedSep 6, 2023
edited by github-actionsbot
Loading

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()
@kumaraditya303kumaraditya303 removed their request for reviewSeptember 12, 2023 17:46
@serhiy-storchakaserhiy-storchaka merged commitadd16f1 intopython:mainSep 17, 2023
@serhiy-storchakaserhiy-storchaka deleted the PyObject_HasAttrWithError-PyMapping_HasKeyWithError branchSeptember 17, 2023 11:23
@bedevere-bot
Copy link

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

Hi! The buildbots390x RHEL8 3.x has failed when building commitadd16f1.

What do you need to do:

  1. Don't panic.
  2. Checkthe 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", line28, intest_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", line146, inprepare    copy_source_tree(srcdir,SRCDIR)  File"/home/dje/cpython-buildarea/3.x.edelsohn-rhel8-z/build/Tools/freeze/test/freeze.py", line95, incopy_source_tree    shutil.copytree(oldroot, newroot,ignore=ignore_non_src)  File"/home/dje/cpython-buildarea/3.x.edelsohn-rhel8-z/build/Lib/shutil.py", line588, incopytreereturn _copytree(entries=entries,src=src,dst=dst,symlinks=symlinks,^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^  File"/home/dje/cpython-buildarea/3.x.edelsohn-rhel8-z/build/Lib/shutil.py", line542, 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 buildbotaarch64 Debian Clang LTO + PGO 3.x has failed when building commitadd16f1.

What do you need to do:

  1. Don't panic.
  2. Checkthe 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", line5475, intest_nested_startmethodself.assertEqual(results, [2,1])AssertionError:Lists differ: [1, 2] != [2, 1]

@bedevere-bot
Copy link

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

Hi! The buildbots390x RHEL7 LTO + PGO 3.x has failed when building commitadd16f1.

What do you need to do:

  1. Don't panic.
  2. Checkthe 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", line788, intest_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", line664, inrun_until_completereturn future.result()^^^^^^^^^^^^^^^  File"/home/dje/cpython-buildarea/3.x.edelsohn-rhel-z.lto-pgo/build/Lib/test/test_asyncio/test_subprocess.py", line780, inmainself.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 buildbotAMD64 Debian root 3.x has failed when building commitadd16f1.

What do you need to do:

  1. Don't panic.
  2. Checkthe 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", line1287, intest_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 buildbotPPC64LE RHEL7 LTO + PGO 3.x has failed when building commitadd16f1.

What do you need to do:

  1. Don't panic.
  2. Checkthe 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", line5475, intest_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", line90, in_callTestMethodifself._callMaybeAsync(method)isnotNone:^^^^^^^^^^^^^^^^^^^^^^^^^^^^  File"/home/buildbot/buildarea/3.x.cstratak-RHEL7-ppc64le.lto-pgo/build/Lib/unittest/async_case.py", line117, 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", line49, inwrapperreturn 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", line1937, intest_fork_signal_handlingself.assertTrue(child_handled.is_set())AssertionError:False is not true

@bedevere-bot
Copy link

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

Hi! The buildbotPPC64LE RHEL8 LTO 3.x has failed when building commitadd16f1.

What do you need to do:

  1. Don't panic.
  2. Checkthe 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", line788, intest_subprocess_consistent_callbacksself.loop.run_until_complete(main())  File"/home/buildbot/buildarea/3.x.cstratak-RHEL8-ppc64le.lto/build/Lib/asyncio/base_events.py", line664, inrun_until_completereturn future.result()^^^^^^^^^^^^^^^  File"/home/buildbot/buildarea/3.x.cstratak-RHEL8-ppc64le.lto/build/Lib/test/test_asyncio/test_subprocess.py", line780, inmainself.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", line90, in_callTestMethodifself._callMaybeAsync(method)isnotNone:^^^^^^^^^^^^^^^^^^^^^^^^^^^^  File"/home/buildbot/buildarea/3.x.cstratak-RHEL8-ppc64le.lto/build/Lib/unittest/async_case.py", line117, in_callMaybeAsyncreturnself._asyncioTestContext.run(func,*args,**kwargs)^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^  File"/home/buildbot/buildarea/3.x.cstratak-RHEL8-ppc64le.lto/build/Lib/test/support/hashlib_helper.py", line49, inwrapperreturn func_or_class(*args,**kwargs)^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^  File"/home/buildbot/buildarea/3.x.cstratak-RHEL8-ppc64le.lto/build/Lib/test/test_asyncio/test_unix_events.py", line1937, intest_fork_signal_handlingself.assertTrue(child_handled.is_set())AssertionError:False is not true

@bedevere-bot
Copy link

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

Hi! The buildbotPPC64LE RHEL7 LTO 3.x has failed when building commitadd16f1.

What do you need to do:

  1. Don't panic.
  2. Checkthe 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", line90, in_callTestMethodifself._callMaybeAsync(method)isnotNone:^^^^^^^^^^^^^^^^^^^^^^^^^^^^  File"/home/buildbot/buildarea/3.x.cstratak-RHEL7-ppc64le.lto/build/Lib/unittest/async_case.py", line117, in_callMaybeAsyncreturnself._asyncioTestContext.run(func,*args,**kwargs)^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^  File"/home/buildbot/buildarea/3.x.cstratak-RHEL7-ppc64le.lto/build/Lib/test/support/hashlib_helper.py", line49, inwrapperreturn func_or_class(*args,**kwargs)^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^  File"/home/buildbot/buildarea/3.x.cstratak-RHEL7-ppc64le.lto/build/Lib/test/test_asyncio/test_unix_events.py", line1937, intest_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 requestSep 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.

encukou reacted with thumbs up emoji
gmarkall added a commit to gmarkall/numba-cuda that referenced this pull requestMay 19, 2025
The simulator needs to be tested with Python 3.12 - it presently doesnot fully work on Python 3.13 due to the change in behaviour for`PyObject_HasAttr()` to no longer silently ignore all errors as it didpreviously.Numba's typecode fingerprinting calls something which is approximately`PyObject_HasAttr("_numba_type_")` on NumPy arrays during some executionpaths of the simulator, which causes NumPy to raise `ValueError("nofield of name _numba_type_")`. Since Python 3.13 this causes masses ofwarnings 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 requestMay 19, 2025
The simulator needs to be tested with Python 3.12 - it presently doesnot fully work on Python 3.13 due to the change in behaviour for`PyObject_HasAttr()` to no longer silently ignore all errors as it didpreviously.Numba's typecode fingerprinting calls something which is approximately`PyObject_HasAttr("_numba_type_")` on NumPy arrays during some executionpaths of the simulator, which causes NumPy to raise `ValueError("nofield of name _numba_type_")`. Since Python 3.13 this causes masses ofwarnings 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 requestMay 20, 2025
The simulator needs to be tested with Python 3.12 - it presently doesnot fully work on Python 3.13 due to the change in behaviour for`PyObject_HasAttr()` to no longer silently ignore all errors as it didpreviously.Numba's typecode fingerprinting calls something which is approximately`PyObject_HasAttr("_numba_type_")` on NumPy arrays during some executionpaths of the simulator, which causes NumPy to raise `ValueError("nofield of name _numba_type_")`. Since Python 3.13 this causes masses ofwarnings 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 requestMay 20, 2025
The simulator needs to be tested with Python 3.12 - it presently doesnot fully work on Python 3.13 due to the change in behaviour for`PyObject_HasAttr()` to no longer silently ignore all errors as it didpreviously.Numba's typecode fingerprinting calls something which is approximately`PyObject_HasAttr("_numba_type_")` on NumPy arrays during some executionpaths of the simulator, which causes NumPy to raise `ValueError("nofield of name _numba_type_")`. Since Python 3.13 this causes masses ofwarnings 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 requestMay 20, 2025
The simulator needs to be tested with Python 3.12 - it presently doesnot fully work on Python 3.13 due to the change in behaviour for`PyObject_HasAttr()` to no longer silently ignore all errors as it didpreviously.Numba's typecode fingerprinting calls something which is approximately`PyObject_HasAttr("_numba_type_")` on NumPy arrays during some executionpaths of the simulator, which causes NumPy to raise `ValueError("nofield of name _numba_type_")`. Since Python 3.13 this causes masses ofwarnings 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 requestMay 27, 2025
The simulator needs to be tested with Python 3.12 - it presently doesnot fully work on Python 3.13 due to the change in behaviour for`PyObject_HasAttr()` to no longer silently ignore all errors as it didpreviously.Numba's typecode fingerprinting calls something which is approximately`PyObject_HasAttr("_numba_type_")` on NumPy arrays during some executionpaths of the simulator, which causes NumPy to raise `ValueError("nofield of name _numba_type_")`. Since Python 3.13 this causes masses ofwarnings 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 requestMay 27, 2025
The simulator needs to be tested with Python 3.12 - it presently doesnot fully work on Python 3.13 due to the change in behaviour for`PyObject_HasAttr()` to no longer silently ignore all errors as it didpreviously.Numba's typecode fingerprinting calls something which is approximately`PyObject_HasAttr("_numba_type_")` on NumPy arrays during some executionpaths of the simulator, which causes NumPy to raise `ValueError("nofield of name _numba_type_")`. Since Python 3.13 this causes masses ofwarnings 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 requestMay 27, 2025
The simulator needs to be tested with Python 3.12 - it presently doesnot fully work on Python 3.13 due to the change in behaviour for`PyObject_HasAttr()` to no longer silently ignore all errors as it didpreviously.Numba's typecode fingerprinting calls something which is approximately`PyObject_HasAttr("_numba_type_")` on NumPy arrays during some executionpaths of the simulator, which causes NumPy to raise `ValueError("nofield of name _numba_type_")`. Since Python 3.13 this causes masses ofwarnings 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 requestMay 27, 2025
The simulator needs to be tested with Python 3.12 - it presently doesnot fully work on Python 3.13 due to the change in behaviour for`PyObject_HasAttr()` to no longer silently ignore all errors as it didpreviously.Numba's typecode fingerprinting calls something which is approximately`PyObject_HasAttr("_numba_type_")` on NumPy arrays during some executionpaths of the simulator, which causes NumPy to raise `ValueError("nofield of name _numba_type_")`. Since Python 3.13 this causes masses ofwarnings 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 requestMay 27, 2025
The simulator needs to be tested with Python 3.12 - it presently doesnot fully work on Python 3.13 due to the change in behaviour for`PyObject_HasAttr()` to no longer silently ignore all errors as it didpreviously.Numba's typecode fingerprinting calls something which is approximately`PyObject_HasAttr("_numba_type_")` on NumPy arrays during some executionpaths of the simulator, which causes NumPy to raise `ValueError("nofield of name _numba_type_")`. Since Python 3.13 this causes masses ofwarnings 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
Reviewers

@vstinnervstinnervstinner left review comments

@scoderscoderscoder left review comments

@methanemethanemethane approved these changes

@markshannonmarkshannonAwaiting requested review from markshannonmarkshannon is a code owner

@encukouencukouAwaiting requested review from encukouencukou is a code owner

Assignees
No one assigned
Labels
topic-C-APItype-featureA feature request or enhancement
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

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

[8]ページ先頭

©2009-2025 Movatter.jp