Author erik.bray
Recipients erik.bray
Date 2017-11-20.09:54:39
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1511171681.08.0.213398074469.issue32082@psf.upfronthosting.co.za>
In-reply-to
Content
In Python 2 it was possible to directly manipulate the list of registered atexit handlers through atexit._exithandlers.  Obviously I'm not complaining that this went away, as it was an underscored attribute.  But this possibility was still useful in the context of testing.

For example, we have a test suite that runs many test cases in subprocesses run with multiprocessing.Process.  Since these call os._exit() any atexit handlers registered by the code under test are not run.  It's useful, however, to test that either

a) Expected atexit handlers ran correctly or
b) No unexpected atexit handlers were registered

To this end we would save and clear atexit._exithandlers, call atexit._run_exitfuncs(), then restore the original atexit._exithandlers.

This is not possible on Python 3 since that all lives in the C module state for sub-interpreter support.  For the time being it was necessary to work around this with a Cython module, but coding around internal extension module structures is hardly ideal: https://git.sagemath.org/sage.git/diff/src/sage/misc/_context_py3.pyx?id=85b17201255e9919eaa7b5cff367e8bc271c2a3f

I think it would be useful--for testing purposes *only*--to add a _get_exitfuncs() function that returns a tuple of the registered handlers, and likewise a _set_exitfuncs(handlers) with sets the registered handlers from an iterable (the latter being little more than a shortcut for `atexit._clear(); for h in handlers: atexit.register(*h)`).

I would propose that these be undocumented internal functions to emphasize that they are not how the module should be used in normal circumstances.  At the same time it might be worth addressing https://bugs.python.org/issue22867  I can provide a patch if this idea is acceptable.
History
Date User Action Args
2017-11-20 09:54:41erik.braysetrecipients: + erik.bray
2017-11-20 09:54:41erik.braysetmessageid: <1511171681.08.0.213398074469.issue32082@psf.upfronthosting.co.za>
2017-11-20 09:54:41erik.braylinkissue32082 messages
2017-11-20 09:54:39erik.braycreate