
On Wed, Apr 22, 2015 at 1:10 PM, Andrew Svetlov <andrew.svetlov@gmail.com> wrote:
On Wed, Apr 22, 2015 at 10:44 PM, PJ Eby <pje@telecommunity.com> wrote:
On Tue, Apr 21, 2015 at 1:26 PM, Yury Selivanov <yselivanov.ml@gmail.com> wrote:
It is an error to pass a regular context manager without ``__aenter__`` and ``__aexit__`` methods to ``async with``. It is a ``SyntaxError`` to use ``async with`` outside of a coroutine.
I find this a little weird. Why not just have `with` and `for` inside a coroutine dynamically check the iterator or context manager, and either behave sync or async accordingly? Why must there be a *syntactic* difference?
IIRC Guido always like to have different syntax for calling regular functions and coroutines. That's why we need explicit syntax for asynchronous context managers and iterators.
To clarify: the philosophy behind asyncio coroutines is that you should be able to tell statically where a task may be suspended simply by looking for `yield from`. This means that *no* implicit suspend points may exist, and it rules out gevent, stackless and similar microthreading frameworks. In the new PEP this would become `await`, plus specific points dictated by `async for` and `async with` -- `async for` can suspend (block) at each iteration step, and `async with` can suspend at the enter and exit points. The use case for both is database drivers: `async for` may block for the next record to become available from the query, and `async with` may block in the implied `finally` clause in order to wait for a commit. (Both may also suspend at the top, but that's less important.) -- --Guido van Rossum (python.org/~guido)