C API functions returns a special value unambiguously signaling about a raised exception (NULL or -1). But in some cases this is ambiguous, because the special value is a legitimate value (e.g. -1 for PyLong_AsLong() or NULL for PyDict_GetItem()). Needed to use PyErr_Occurred() to distinguish between successful and failed call.

The problem is that if PyLong_AsLong() is called when the exception is set, successful call returned -1 is interpreted as failed. Since it is happen in very rare case, this bug is usually unnoticed.

Attached experimental patch makes some functions like PyLong_AsLong() always failing if called with an exception set. Some tests are failed with it applied: test_compile test_datetime test_io test_os test_symtable test_syntax test_xml_etree_c.

Ah yes. Some months (years?) ago, i started to add assertions to fail if
some functions are called with an exception set.

Checking if an exception is set at runtime adds a low overhead. Maybe it's
better to fail with a fatal error (like an assertion error) in debug mode
(and do nothing in release mode).

But I'm not sure that developers of C extensions are all able to get a
Python compiled in debug mode :-/ That's also why I added a check a
runtime: raise a SystemError if a function with an exception set. I also
added PYTHONMALLOC=debug to make some debug checks easily available on
release builds.

The bug also reminds me my PEP 490 to chain exceptions. It would be
yet another option...

So well, I don't know what is the best option.