In this case, I was able to change my code to require the context be established outside of the call to the asynchronous generator. It puts more burden on the caller to setup context before making the call.
Without a solution in place, is there a legitimate case for a context manager being entered (and not exited) within a generator iteration? If not, would some kind of warning be appropriate (or even possible)?
On Thu, 2020-12-31 at 21:49 +0000, Brendan Moloney wrote:
This bit me a while back, and I spent some time reading through the PEP 533 discussion. It was determined that changing the default behavior of for loops would break too much code.
I wonder if the new PEG parser would allow us to decorate for loops with context sensitive keywords to override this default behavior without requiring code restructuring (adding a with statement).
From: Paul Bryan via Python-ideas firstname.lastname@example.org Sent: Thursday, December 31, 2020 12:06 PM To: email@example.com Subject: [EXTERNAL] [Python-ideas] PEP 533 Redux? I've now encountered an issue I believe that PEP 533 was intended to address:
When an asynchronous context manager is created within an asynchronous generator, if the generator is not iterated fully, the context manager will not exit until the event loop cancels the task by raising a CancelledError, long after the context manager is assumed to be out of scope. Per PEP 525, I can call aclose coroutine method to cleanup the generator, but it requires the code iterating to be aware that that closing the generator is necessary.
Any appetite for putting PEP 533 back on the table to address this issue?
Python-ideas mailing list -- firstname.lastname@example.org To unsubscribe send an email to email@example.com https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://firstname.lastname@example.org/message/4OYH7Y... Code of Conduct: http://python.org/psf/codeofconduct/