[issue32082] atexit module: allow getting/setting list of handlers directly

[Irit Katriel]

Irit Katriel  added the comment:

Yes, I agree this should be closed as a duplicate of issue17186. The shortcut 
for updating the list of handlers is not really necessary because the API 
already allows you to do this.

--
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> no way to introspect registered atexit handlers

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32082] atexit module: allow getting/setting list of handlers directly

[Mark Dickinson]

Mark Dickinson  added the comment:

Thanks, Irit. Should we close this issue as a duplicate? It's not identical 
(being able to modify the list of handlers versus just being able to inspect 
it), but it's pretty close.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32082] atexit module: allow getting/setting list of handlers directly

[Irit Katriel]

Irit Katriel  added the comment:

See also issue17186.

--
nosy: +iritkatriel

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32082] atexit module: allow getting/setting list of handlers directly

[Mark Dickinson]

Mark Dickinson  added the comment:

You say "for testing purposes only", but I'd add "for debugging" to the list of 
use-cases, having just spent a few hours trying to understand why I was getting 
a particular PySide2 "Internal C++ object already deleted." exception under 
Python 3.6 but not under Python 3.7 and later. [*]

Even just making the list of exit handlers introspectable (so just 
_get_exitfuncs()) would have been really useful in diagnosing the issue faster.



[*] The answer turned out to be that under Python 3.6 the PySide2 exit handler 
was being run before the concurrent.futures thread-cleanup exit handler, while 
on Python 3.7, for obscure reasons, the exit handlers were being registered in 
the reverse order. To discover this, I ended up resorting to the elegant hack 
(if that's not a contradiction in terms) described in 
https://stackoverflow.com/a/63029332/270986

--
nosy: +mark.dickinson

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32082] atexit module: allow getting/setting list of handlers directly

[Xtrem532]

Change by Xtrem532 :


--
nosy: +Xtrem532

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32082] atexit module: allow getting/setting list of handlers directly

[Christopher Hunt]

Christopher Hunt  added the comment:

Updated link to workaround referenced in the original issue: 
https://github.com/sagemath/sage/blob/b5c9cf037cbce672101725f269470135b9b2c5c4/src/sage/cpython/atexit.pyx

--
nosy: +chrahunt

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32082] atexit module: allow getting/setting list of handlers directly

[Erik Bray]

New submission from Erik Bray :

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.

--
components: Library (Lib)
messages: 306537
nosy: erik.bray
priority: normal
severity: normal
status: open
title: atexit module: allow getting/setting list of handlers directly
type: behavior

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com