no way to introspect registered atexit handlers

[cjw296]

BPO	17186
Nosy	@warsaw, @pitrou, @cjw296, @iritkatriel

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = None
created_at = <Date 2013-02-11.22:35:30.870>
labels = ['type-feature', 'library', '3.11']
title = 'no way to introspect registered atexit handlers'
updated_at = <Date 2021-11-30.16:59:52.647>
user = 'https://github.com/cjw296'

bugs.python.org fields:

activity = <Date 2021-11-30.16:59:52.647>
actor = 'iritkatriel'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Library (Lib)']
creation = <Date 2013-02-11.22:35:30.870>
creator = 'cjw296'
dependencies = []
files = []
hgrepos = []
issue_num = 17186
keywords = []
message_count = 8.0
messages = ['181935', '182683', '182684', '182685', '182686', '182688', '182692', '396594']
nosy_count = 5.0
nosy_names = ['barry', 'pitrou', 'cjw296', 'neologix', 'iritkatriel']
pr_nums = []
priority = 'normal'
resolution = None
stage = None
status = 'open'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue17186'
versions = ['Python 3.11']

[cjw296]

Python 2 had a private but usable way of introspecting and manipulating registered atexit handlers by way of the atexit._exithandlers.

In Python 3, registering and unregistering are handled, but there is no longer a way to see what atexit handlers are registered.

Barry suggested filing a bug to have this added as a new feature for Python 3.4. Some kind of read-only sequence would be fine, if the original list can no longer be exposed.

[neologix]

Could you please give an example of why this would be a useful addition?
I can see the usage of removing a handler, but the user should know which handlers are registered.

[cjw296]

Barry advised me to open this issue as it's a functional regression from Python 2.

My use case is unit testing code that registers atexit handlers and making sure the right handlers are registered with the correct parameters.

[neologix]

Barry advised me to open this issue as it's a functional regression from Python 2.

But it was relying on a private and non documented feature in Python
2, so it's not really a regression.

My use case is unit testing code that registers atexit handlers and making sure the right handlers are registered with the correct parameters.

IMO, complicating an API for testing purpose is a bad idea.

[cjw296]

I can think of other use cases. Anyway, I'm just glad your opinion isn't the only one there is ;-)

[pitrou]

I don't think you want your test suite to run your atexit handlers at exit, so you should probably mock atexit.register instead.

[warsaw]

On Feb 22, 2013, at 06:54 PM, Charles-François Natali wrote:

Charles-François Natali added the comment:

> Barry advised me to open this issue as it's a functional regression from
> Python 2.

But it was relying on a private and non documented feature in Python
2, so it's not really a regression.

I also suggested it would have to be considered a new feature for 3.4.

[iritkatriel]

See also bpo-32082.

[matthiasdiener]

A hacky way to see which handlers are registered is discussed here: https://stackoverflow.com/a/63029332/1250282.

[cjw296]

It's sad that this hack is needed, I really do think there should be a way to introspect what exit handler are currently registered. New feature or regression from 2.7, either way, it would be great to have this functionality given the set of folks that want it.