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 holdenweb
Recipients holdenweb, r.david.murray
Date 2014-07-02.14:03:36
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
I believe (though my belief is untrammeled by anything as useful as knowledge of the code: my diagnostic skills are largely psychic) that the cell essentially takes over the reference from the local namespace of the about-to-terminate lexically surrounding function.

This would appear to be a logical time to create closure cells, as there is effectively no need to create them for functions that will be destroyed. So I imagine any remaining function objects accessible from the return expression will be fixed up at that point. This has the rather unpleasant side effect of capturing the value on surrounding function return rather than closure function creation.

The behavior exhibited, in my opinion, shows that there would be strong advantages to creating the closures dynamically, even though I can understand that pathological cases might require much work. It might have to be benchmarked before a decision, I suppose. I couldn't say off-hand how many people are dynamically trying to create multiple closures from a single namespace. It seems to me that the principle of least surprise would suggest a change be adopted, but I may be the only one who's surprised.

I have documented this issue in more detail on my blog at

and will report back if anything of substance emerges. Otherwise I'll just leave this closed. Thanks for your comment and consideration.
Date User Action Args
2014-07-02 14:03:37holdenwebsetrecipients: + holdenweb, r.david.murray
2014-07-02 14:03:37holdenwebsetmessageid: <>
2014-07-02 14:03:37holdenweblinkissue21904 messages
2014-07-02 14:03:36holdenwebcreate