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 izbyshev
Recipients izbyshev, steve.dower, vstinner
Date 2020-12-04.16:12:33
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1607098353.32.0.624763724813.issue42569@roundup.psfhosted.org>
In-reply-to
Content
Before addition of audit hooks in 3.8, _Py_fopen() and _Py_wfopen() were simple wrappers around corresponding C runtime functions. They didn't require GIL, reported errors via errno and could be safely called during early interpreter initialization.

With the addition of PySys_Audit() calls, they can also raise an exception, which makes it unclear how they should be used. At least one caller[1] is confused, so an early-added hook (e.g. from sitecustomize.py) that raises a RuntimeError on at attempt to open the main file causes the following:

$ ./python /home/test/test.py
./python: can't open file '/home/test/test.py': [Errno 22] Invalid argument
Traceback (most recent call last):
  File "/home/test/.local/lib/python3.10/site-packages/sitecustomize.py", line 10, in hook
    raise RuntimeError("XXX")
RuntimeError: XXX

"Invalid argument" is reported by pymain_run_file() due to a bogus errno, and the real problem (exception from the hook) is noticed only later.

Could somebody share the current intended status/role of these helpers? Understanding that seems to be required to deal with issue 32381.

[1] https://github.com/python/cpython/blob/066394018a84/Modules/main.c#L314
History
Date User Action Args
2020-12-04 16:12:33izbyshevsetrecipients: + izbyshev, vstinner, steve.dower
2020-12-04 16:12:33izbyshevsetmessageid: <1607098353.32.0.624763724813.issue42569@roundup.psfhosted.org>
2020-12-04 16:12:33izbyshevlinkissue42569 messages
2020-12-04 16:12:33izbyshevcreate