-
-
Notifications
You must be signed in to change notification settings - Fork 32.2k
gh-101100: Clean up Doc/c-api/exceptions.rst and Doc/c-api/sys.rst #114825
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from 6 commits
5342ffc
d8a1b7a
384f1c6
e721a94
0a428a3
2aa2771
bf7297c
30427f5
bba6ff6
67c1ac2
f96de13
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -5,6 +5,7 @@ | |
Operating System Utilities | ||
========================== | ||
|
||
|
||
.. c:function:: PyObject* PyOS_FSPath(PyObject *path) | ||
|
||
Return the file system representation for *path*. If the object is a | ||
|
@@ -97,27 +98,30 @@ Operating System Utilities | |
|
||
.. c:function:: int PyOS_CheckStack() | ||
|
||
.. index:: single: USE_STACKCHECK (C macro) | ||
|
||
Return true when the interpreter runs out of stack space. This is a reliable | ||
check, but is only available when :c:macro:`USE_STACKCHECK` is defined (currently | ||
check, but is only available when :c:macro:`!USE_STACKCHECK` is defined (currently | ||
on certain versions of Windows using the Microsoft Visual C++ compiler). | ||
:c:macro:`USE_STACKCHECK` will be defined automatically; you should never | ||
:c:macro:`!USE_STACKCHECK` will be defined automatically; you should never | ||
change the definition in your own code. | ||
|
||
|
||
.. c:type:: void (*PyOS_sighandler_t)(int) | ||
|
||
|
||
.. c:function:: PyOS_sighandler_t PyOS_getsig(int i) | ||
|
||
Return the current signal handler for signal *i*. This is a thin wrapper around | ||
either :c:func:`!sigaction` or :c:func:`!signal`. Do not call those functions | ||
directly! :c:type:`PyOS_sighandler_t` is a typedef alias for :c:expr:`void | ||
(\*)(int)`. | ||
directly! | ||
|
||
|
||
.. c:function:: PyOS_sighandler_t PyOS_setsig(int i, PyOS_sighandler_t h) | ||
|
||
Set the signal handler for signal *i* to be *h*; return the old signal handler. | ||
This is a thin wrapper around either :c:func:`!sigaction` or :c:func:`!signal`. Do | ||
not call those functions directly! :c:type:`PyOS_sighandler_t` is a typedef | ||
alias for :c:expr:`void (\*)(int)`. | ||
not call those functions directly! | ||
|
||
.. c:function:: wchar_t* Py_DecodeLocale(const char* arg, size_t *size) | ||
|
||
|
@@ -342,10 +346,15 @@ accessible to C code. They all work with the current interpreter thread's | |
silently abort the operation by raising an error subclassed from | ||
:class:`Exception` (other errors will not be silenced). | ||
|
||
The hook function is of type :c:expr:`int (*)(const char *event, PyObject | ||
*args, void *userData)`, where *args* is guaranteed to be a | ||
:c:type:`PyTupleObject`. The hook function is always called with the GIL | ||
held by the Python interpreter that raised the event. | ||
.. c:namespace:: NULL | ||
.. c:type:: int (*Py_AuditHookFunction) (const char *event, PyObject *args, void *userData) | ||
|
||
The type of the hook function. | ||
*event* is (the event argument passed to PySys_Audit() or PySys_AuditTuple()), | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Wait, I used parentheses to denote that it is a preliminary text, and that you should rewrite it in good English. Perhaps it is even better to describe parameters not in terms of PySys_Audit() or PySys_AuditTuple(), but in more general terms. Look at There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Ah, I recognized "(...)" as a placeholder, not the more elaborate parenthesized phrasing. Will get back to it. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
I thought about that, but am not familiar enough with the C API documentation to know that descriptions of function prototypes don't simply rely on the actual prototype. |
||
*args* is guaranteed to be a :c:type:`PyTupleObject`. The hook | ||
function is always called with the GIL held by the Python | ||
interpreter that raised the event. | ||
*userData* is the argument passed to PySys_AddAuditHook(). | ||
smontanaro marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
||
See :pep:`578` for a detailed description of auditing. Functions in the | ||
runtime and standard library that raise events are listed in the | ||
|
Uh oh!
There was an error while loading. Please reload this page.