classification
Title: Remove _PyObject_HasAttrId
Type: behavior Stage: resolved
Components: Interpreter Core Versions: Python 3.10
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: Nosy List: pablogsal, serhiy.storchaka, vstinner
Priority: normal Keywords: patch

Created on 2020-10-10 07:47 by serhiy.storchaka, last changed 2020-10-11 12:30 by vstinner. This issue is now closed.

Pull Requests
URL Status Linked Edit
PR 22629 merged serhiy.storchaka, 2020-10-10 07:49
Messages (4)
msg378370 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2020-10-10 07:47
_PyObject_HasAttrId() can return -1, 0 or 1. It returns -1 when cannot create a string (most likely due to MemoryError or UnicodeDecodeError), but returns 0 and silences all exceptions raised when look up the attribute (including MemoryError, KeybordInterruptError and RecursionError). Silencing arbitrary exceptions is bad, and the interface of the function is inconsistent, so it is better to remove it and replace all 5 of its occurrences in 3 files with _PyObject_LookupAttrId(). It is private API, so we can do it without breaking user code.
msg378371 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2020-10-10 07:54
This function was kept after previous clean because all its usages was in the code which silences all exceptions in any case, so using _PyObject_HasAttrId did not do additional harm. But now it is used also in the new code in Objects/unionobject.c. It is safer to not only fix Objects/unionobject.c, but remove _PyObject_HasAttrId at all.
msg378413 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2020-10-10 19:23
New changeset 98c4433a81a4cd88c7438adbee1f2aa486188ca3 by Serhiy Storchaka in branch 'master':
bpo-41991: Remove _PyObject_HasAttrId (GH-22629)
https://github.com/python/cpython/commit/98c4433a81a4cd88c7438adbee1f2aa486188ca3
msg378429 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2020-10-11 12:30
Remark: the issue that you give in this issue is helpful. Next time, you may include such rationale directly in the commit message. IMO the Linux kernel is a great example on how commit message should be written: long commit message with tons of information, you don't need to go to an online website (like bugs.python.org) to get more context / the rationale.
History
Date User Action Args
2020-10-11 12:30:42vstinnersetmessages: + msg378429
2020-10-10 21:07:06serhiy.storchakasetstatus: open -> closed
stage: patch review -> resolved
resolution: fixed
versions: - Python 3.8, Python 3.9
2020-10-10 19:23:50serhiy.storchakasetmessages: + msg378413
2020-10-10 07:54:47serhiy.storchakasetnosy: + vstinner, pablogsal
messages: + msg378371
2020-10-10 07:49:30serhiy.storchakasetkeywords: + patch
stage: patch review
pull_requests: + pull_request21606
2020-10-10 07:47:11serhiy.storchakacreate