This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author vstinner
Recipients serhiy.storchaka, vstinner
Date 2020-10-11.22:24:24
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1602455064.42.0.970715591586.issue42006@roundup.psfhosted.org>
In-reply-to
Content
PyDict_GetItem() behavior is an old wart. Would it make sense to plan a migration plan to slowly move towards PyDict_GetItem() behaving as PyDict_GetItemWithError()?

CPython is an old code base full of corner cases. But outside CPython, is it common to rely on the current PyDict_GetItem() behavior (ignore errors, can be called with an exception raised)?

(A) For example, would it make sense to start to emit a DeprecationWarning when it's called with an exception raised? Currently, the function calls _PyErr_Fetch(): checking if exc_type is non-NULL requires to add an if which would add a cost to all PyDict_GetItem() calls. But IMO it would be interesting to fix this function in the long term.

(B) Also, would it make sense to start to no longer ignore base exceptions like SystemExit, KeyboardInterrupt or MemoryError in PyDict_GetItem()?

How can we take a decision on that? Analyze the C code base of a bunch of popular C extension? Make the change and await to see how many people complain?

In the long term, I would prefer that PyDict_GetItem() behaves as other C functions: it should not be called with an exception raised (the caller has to store/restore the current exception), and raises an exception on error. I expect better performance for such more regular and simpler behavior.
History
Date User Action Args
2020-10-11 22:24:24vstinnersetrecipients: + vstinner, serhiy.storchaka
2020-10-11 22:24:24vstinnersetmessageid: <1602455064.42.0.970715591586.issue42006@roundup.psfhosted.org>
2020-10-11 22:24:24vstinnerlinkissue42006 messages
2020-10-11 22:24:24vstinnercreate