This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author larry
Recipients benjamin.peterson, docs@python, eric.araujo, georg.brandl, giampaolo.rodola, larry, loewis, meador.inge, neologix, pitrou, python-dev, rhettinger, terry.reedy
Date 2012-07-16.04:56:25
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1342414586.93.0.408246161863.issue15233@psf.upfronthosting.co.za>
In-reply-to
Content
I have been meditating on this, and I'm not sure we should change 2.7.  3.2 might be okay.

The thing is, I fear we're not just talking about CPython implementation details, we're talking about the Python Standard Library.  The existing documentation clearly gives alternative implementations free license to call atexit registered functions in any order they like.  So it's conceivable that other implementations don't guarantee reverse order.

I don't know what the right thing is to do here.  It seems like we could define atexit's behavior for 2.7 *if* all the major alternative implementations happily also implicitly guarantee reverse order.  Failing that we probably shouldn't touch it.  Or we could just document that reverse order is guaranteed in CPython only.

Of course, there are no alternative implementations that support 3.2.  That's why I think 3.2 might be okay.  It does seem strange to redefine part of the implicit language spec more than a year after the release shipped though.
History
Date User Action Args
2012-07-16 04:56:27larrysetrecipients: + larry, loewis, georg.brandl, rhettinger, terry.reedy, pitrou, giampaolo.rodola, benjamin.peterson, eric.araujo, meador.inge, neologix, docs@python, python-dev
2012-07-16 04:56:26larrysetmessageid: <1342414586.93.0.408246161863.issue15233@psf.upfronthosting.co.za>
2012-07-16 04:56:26larrylinkissue15233 messages
2012-07-16 04:56:25larrycreate