Steve Holden added the comment: 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 http://holdenweb.blogspot.co.uk/2014/07/closures-arent-easy.html and will report back if anything of substance emerges. Otherwise I'll just leave this closed. Thanks for your comment and consideration. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue21904> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
