GeezerVison

Can you please list affected functions?

Is there a way to mute these warnings if an application is affected by this change but the maintainer is not available in the short term to fix these issues? These APIs were ignoring silently errors for years.

Maybe we need a command line option and/or environment variable to set an unraisable hook which... Does nothing.

In code, I suppose that it's easy to do:

import sys
def silence_errors(args):
    pass
sys.unraisablehook=silence_errors

I made a similar change in Python 3.13 io module: close() errors are now logged.

I listed them in the NEWS entry. Will add them to the commit message too.

There are no new reports in the CPython tests, so at least CPython code is almost clear. They can still occur if you press Ctrl-C or run program in memory constricted environment, but it is very unlikely.

I think that the problem of silencing unraisable exception messages is a separate issue. It may be even not too important issue if such messages are rare. In addition to "silence error" I would consider adding option for "abort immediately".

Oh sure, you can abort the process on the first unraisable exception:

import signal, sys

def abort_hook(unraisable):
    signal.raise_signal(signal.SIGABRT)

sys.unraisablehook = abort_hook

A better implementation may want to log the exception before 😁 Maybe by calling the old hook.

At the beginning, it was proposed to always crash the process.

• https://bugs.python.org/issue36829
• https://vstinner.github.io/sys-unraisablehook-python38.html

Are you suggesting command line and env var to get his behavior?

pytest now catchs these unraisable exceptions.

I listed them in the NEWS entry

Oh sorry I miss it, thanks.

Would it be possible to suggest a fix in the warning? Like using an API which report errors?

Are you suggesting command line and env var to get his behavior?

It is a different issue, but I would be interested in such feature. Not that I need it now, but if I need it, it would be useful.

Would it be possible to suggest a fix in the warning? Like using an API which report errors?

On one hand, it would help the author of the extension. On other hand, it will overwhelm the user of the extension with not useful information. Should I keep the current more general description?

Exception ignored on testing a mapping key:
Exception ignored in PyMapping_HasKey(); use PyMapping_GetOptionalItem() or PyObject_GetItem() instead:
Exception ignored on testing a mapping key in PyMapping_HasKey(); use PyMapping_GetOptionalItem() or PyObject_GetItem() instead:

I would prefer to suggest using a different function to avoid such warning. About the phrasing, you may write "...; consider using xxx()".

I'm also fine with the shorter error message.

Unrelated note: we should consider making _PyErr_WriteUnraisableMsg() a public function.

I would prefer richer API, similar to PyErr_Format().

I would prefer richer API, similar to PyErr_Format().

That sounds like a good idea :-)

Do you need help to solve conflicts? I approved your PR but you didn't merge it yet. Do you plan further changes?

I could merge this PR long time ago, but I wanted to do some things before to make this PR better:

• Add tests for PyObject_HasAttr(), PyMapping_HasKey(), etc. (Add the C API tests for Mapping Protocol and Sequence Protocol #107178)
• Add tests for PySys_GetObject(). (Add C API tests for PySys_GetObject() and PySys_SetObject() #107735)
• Enhance PyErr_WriteUnraisable() API. ([C API] Enhance PyErr_WriteUnraisable() API to pass an error message #108082)
• Add replacements for PyObject_HasAttr(), PyMapping_HasKey(), etc. (C API: Add replacements for PyObject_HasAttr() etc #108511)
• Add a replacement for PySys_GetObject(). (C API: Add a replacement for PySys_GetObject #108512)

Of course it can be merged before implementing all steps above, but then we will need to return to this code to improve it.

Updated, improved warning messages.

Adding a replacement for PySys_GetObject() is more controversial, so it is better to merge this PR first.

If these warnings become a performance issue later, maybe we can compute some fixed strings as static strings, like _Py_STR() API.

In the What's New, would it be possible to mention recommended replacement function(s), maybe as a list (func: replace)?

In the What's New, would it be possible to mention recommended replacement function(s), maybe as a list (func: replace)?

They are already mentioned in the documentation for corresponding functions.