On Wed, Jan 9, 2013 at 4:32 AM, Guido van Rossum <guido@python.org> wrote:
On Tue, Jan 8, 2013 at 2:13 AM, Nick Coghlan <ncoghlan@gmail.com> wrote:
On Tue, Jan 8, 2013 at 11:06 AM, Guido van Rossum <guido@python.org> wrote:
On Sun, Jan 6, 2013 at 9:47 PM, Nick Coghlan <ncoghlan@gmail.com> wrote:
Ah, true, I hadn't thought of that. So yes, any case where the __exit__ method can be "fire-and-forget" is also straightforward to implement with just PEP 3156. That takes us back to things like database transactions being the only ones where
And 'yielding' wouldn't do anything about this, would it?
Any new syntax should properly handle the database transaction context manager problem, otherwise what's the point? The workarounds for asynchronous __next__ and __enter__ methods aren't too bad - it's allowing asynchronous __exit__ methods that can only be solved with new syntax.
Is your idea that if you write "with yielding x as y: blah" this effectively replaces the calls to __enter__ and __exit__ with "yield from x.__enter__()" and "yield from x.__enter__()"? (And assigning the result of yield fro, x.__enter__() to y.)
Yep - that's why it would need a new keyword, as the subexpression itself would be evaluated normally, while the later special method invocations would be wrapped in yield from expressions.
However, note that I just wanted to be clear that I consider the idea of a syntax for "asynchronous context managers" plausible, and sketched out a possible design to explain *why* I thought it should be possible. My focus will stay with PEP 432 until that's done.
Sure, I didn't intend any time pressure. Others may take this up as well -- or if nobody cares, we can put it off until the need has been demonstrated more. possibly after Python 3.4 is release.
Yep - the fact you can fall back to an explicit try-finally if needed, or else use something like gevent to suspend implicitly if you want to use such idioms a lot makes it easy to justify postponing doing anything about it. I'll at least mention the idea in my python-notes essay, though. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia