Reading through the PEP again and some of the discussion, I think I now better understand the issue.
If we were to undertake a change in for's behavior, unless the generator is actually explicitly scoped to the for statement (and doesn't survive outside of the loop, which is not how it works today), closing would not make sense, and could expose other undesirable side- effects. The generator consumer would need to be aware that it needs to be closed (or aclosed) and do so explicitly. Problematic example I can think of: partially iterating the generator, terminating the loop, doing something, then continuing to iterate. I'm not a fan of adding a keyword to a for loop to do explicit closing. My takeaway with what I know now: I now consider generators establishing context(s) to be an anti-pattern. I've now refactored my code to require the context to be in place prior to the creation of the generator. In my case, it actually makes it far easier for the API consumer to reason about the scope of the context and behavior of the generator. Explicit is better than implicit. Thanks to you and to everyone else that have discussed this. Paul On Wed, 2021-01-06 at 21:24 +0000, Brendan Moloney wrote: > I mentioned this off-hand in the other thread, but the more I think > about it the more I think it is a reasonable compromise between the > two schools of thought on PEP 533. > > Wouldn't the new PEG parser allow a "closed for" statement without > breaking code that uses "closed" as a variable (it would be a context > sensitive keyword)? > > The users who work in the space that cares about such things can > start writing: > closed for document in read_newline_separated_json(path): > ... > Instead of: > with closing(read_newline_separated_json(path)) as genobj: > for document in genobj: > ... > > It is still on the API consumer to know when they need to use a > "closed for" loop, but at least they don't have to restructure their > code, and there would be no backwards incompatibility. > > If we want to get really crazy we can also allow an "open for" loop > and kick off a very long deprecation process where eventually an > unadorned for loop would become "closed" by default. > > Thanks, > Brendan > _______________________________________________ > Python-ideas mailing list -- [email protected] > To unsubscribe send an email to [email protected] > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/[email protected]/message/MZIVRIM5JLS5YOAEVBIJFHVROZ3AJRI5/ > Code of Conduct: http://python.org/psf/codeofconduct/
_______________________________________________ Python-ideas mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/HMJBQ7MBN6XSTQB7ND7WLL66NMIT3RXU/ Code of Conduct: http://python.org/psf/codeofconduct/
