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 ncoghlan
Recipients Yury.Selivanov, akvadrako, asvetlov, benjamin.peterson, eric.snow, meador.inge, ncoghlan, pitrou, rhettinger, sbt
Date 2017-10-12.02:46:41
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1507776401.76.0.213398074469.issue14369@psf.upfronthosting.co.za>
In-reply-to
Content
Thinking about the interaction between this idea and https://bugs.python.org/issue30744 made me realise that there's a subtlety here that would probably need to be spelled out more clearly in the docs for __closure__ than it is for __code__: any changes made to a function object (whether it's a synchronous function, a generator, or a coroutine) will only affect *future* function invocations, as execution frames capture references to both the code object and all the closure cells when they're created.

(Thought prompted by asking myself "What would happen to existing generator-iterators if you rebound the closure on the generator function?". The answer is "Nothing", but I figure if I had to think about it, that answer likely isn't going to be obvious to folks that are less familiar with how the eval loop works in practice)
History
Date User Action Args
2017-10-12 02:46:41ncoghlansetrecipients: + ncoghlan, rhettinger, pitrou, benjamin.peterson, asvetlov, meador.inge, Yury.Selivanov, sbt, eric.snow, akvadrako
2017-10-12 02:46:41ncoghlansetmessageid: <1507776401.76.0.213398074469.issue14369@psf.upfronthosting.co.za>
2017-10-12 02:46:41ncoghlanlinkissue14369 messages
2017-10-12 02:46:41ncoghlancreate