homepage

import atexit
@atexit.register
def goodbye1():
 print(1)
 
@atexit.register
def goodbye2():
 print(2)
The code above prints:
2
1
...that is, the last registered function is executed first.
Wouldn't the contrary be better?

I'm sure you can craft cases where one order is preferable to
another, but I don't think you can make the case in general
that first in, first out is preferable to last in, first out,
or any other ordering of exit functions.

I think it's not a matter of "preferable" but "most expected" and I see FIFO as the most expected behavior in this case.

LIFO looks preferable if you want your setup/teardown code to be properly nested (that is, if I set up A before B, I want B to be torn down before A).

It seems to me that atexit is simple by design: It registers callables that do one thing, period. If you have dependencies in your cleanup code, you should write a function doing the Right ThingTM and register that. This keeps the implementation simple, otherwise we’d have to debate LIFO vs. FIFO, adding an argument to register vs. exposing the list of callables, etc.
If you agree, I could make a patch to make the docs more explicit about atexit’s simplicity and lack of guarantee about run order.

I don't think the order should be defined.

Ok, I'll shut up then. =)
> If you agree, I could make a patch to make the docs more explicit about 
> atexit’s simplicity and lack of guarantee about run order.
Sure, go ahead.

I agree with Antoine's LIFO comment. Also, FWIW, the C standard library behaves in a LIFO manner as well (C99 spec - 7.20.4.3 clause 3):
"First, all functions registered by the atexit function are called, in the reverse order of their registration,253) except that a function is called after any previously registered functions that had already been called at the time it was registered. If, during the call to any such function, a call to the longjmp function is made that would terminate the call to the registered function, the behavior is undefined."

Here’s a patch.

> I don't think the order should be defined.
I disagree.
The C standard explicitely states that the functions are called in LIFO order (which is the natural order in this case).
The current implementation guarantees LIFO order, I think it should be documented.

New changeset e37fa30c4be4 by Éric Araujo in branch '3.2':
Document that atexit execution order is undefined (#9788)
http://hg.python.org/cpython/rev/e37fa30c4be4 

New changeset df415bfbb652 by Éric Araujo in branch '2.7':
Document that atexit execution order is undefined (#9788)
http://hg.python.org/cpython/rev/df415bfbb652 

Given Benjamin and Giampaolo’s support, I committed my patch, so that at least the current behavior is documented. I personally have no opinion on LIFO vs. FIFO vs. undefined; I just think that the atexit module is not a wrapper around C’s atexit, and as such not bound by the same rules, and undefined sounds fine. If you feel very strongly about that, then please follow up on python-dev.

Thanks. After all, I think that "keeping atexit simple" is the best solution and a doc adjustement is just fine.

Reopened as #15233.