[issue9788] atexit and execution order

Éric Araujo added the comment: Reopened as #15233. -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://ma

[issue9788] atexit and execution order

Giampaolo Rodola' added the comment: Thanks. After all, I think that "keeping atexit simple" is the best solution and a doc adjustement is just fine. -- ___ Python tracker ___ _

[issue9788] atexit and execution order

Éric Araujo added the comment: 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 n

[issue9788] atexit and execution order

Roundup Robot added the comment: 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 -- ___ Python tracker

[issue9788] atexit and execution order

Roundup Robot added the comment: 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 -- nosy: +python-dev ___ Python tracker

[issue9788] atexit and execution order

Charles-François Natali added the comment: > 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

[issue9788] atexit and execution order

Éric Araujo added the comment: Here’s a patch. -- keywords: +needs review, patch resolution: accepted -> stage: needs patch -> patch review versions: +Python 3.3 -Python 3.1 Added file: http://bugs.python.org/file22318/doc-atexit-order-undefined.diff __

[issue9788] atexit and execution order

Changes by Skip Montanaro : -- nosy: -skip.montanaro ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mai

[issue9788] atexit and execution order

Meador Inge added the comment: 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 t

[issue9788] atexit and execution order

Changes by Éric Araujo : -- assignee: -> eric.araujo components: +Documentation -Library (Lib) resolution: -> accepted stage: -> needs patch versions: +Python 2.7, Python 3.1 ___ Python tracker __

[issue9788] atexit and execution order

Giampaolo Rodola' added the comment: 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. -- ___ Python tracker

[issue9788] atexit and execution order

Benjamin Peterson added the comment: I don't think the order should be defined. -- nosy: +benjamin.peterson ___ Python tracker ___ ___

[issue9788] atexit and execution order

Éric Araujo added the comment: 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 Thing™ and register that. This keeps the implementation simple, otherwise

[issue9788] atexit and execution order

Antoine Pitrou added the comment: 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). -- nosy: +pitrou ___ Python tracker

[issue9788] atexit and execution order

Giampaolo Rodola' added the comment: I think it's not a matter of "preferable" but "most expected" and I see FIFO as the most expected behavior in this case. -- ___ Python tracker _

[issue9788] atexit and execution order

Changes by Éric Araujo : -- nosy: +eric.araujo ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pytho

[issue9788] atexit and execution order

Skip Montanaro added the comment: 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. -- nosy: +skip.montanaro __

[issue9788] atexit and execution order

New submission from Giampaolo Rodola' : 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? -- components