On Sep 25, 2018, at 03:44, Victor Stinner <vstin...@redhat.com> wrote:
> By the way, recently, we had to fix yet another bug in signal
> handling. A new function has been added:
>
> void
> _PyEval_SignalReceived(void)
> {
> /* bpo-30703: Function called when the C signal handler of Python gets a
> signal. We cannot queue a callback using Py_AddPendingCall() since
> that function is not async-signal-safe. */
> SIGNAL_PENDING_CALLS();
> }
Is anybody else concerned about the proliferation of undocumented private C API
functions? I’m fine with adding leading underscore functions and macros when
it makes sense, but what concerns me is that they don’t appear in the Python C
API documentation (AFAICT). That means they are undiscoverable, and their
existence and utility is buried in institutional knowledge and obscure places
within the C code. And yet, the interpreter relies heavily on them.
Maybe this is better off discussed in doc-sig but I think we need to consider
documenting the private C API.
-Barry
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
