[Python-Dev] PEP 492: No new syntax is required

[Brett Cannon]

 On Sun, Apr 26, 2015, 17:49 Mark Shannon <mark at hotpy.org> wrote:

On 26/04/15 21:40, Yury Selivanov wrote:
> Hi Mark,
>
> On 2015-04-26 4:21 PM, Mark Shannon wrote:
>> Hi,
>>
>> I was looking at PEP 492 and it seems to me that no new syntax is
>> required.
>
> Mark, all your points are explained in the PEP in a great detail:
I did read the PEP. I do think that clarifying the distinction between
coroutines and 'normal' generators is a good idea. Adding stuff to the
standard library to help is fine. I just don't think that any new syntax
is necessary.

>
>>
>> Looking at the code, it does four things; all of which, or a
>> functional equivalent, could be done with no new syntax.
>
> Yes, everything that the PEP proposes can be done without new syntax.
> That's how people use asyncio right now, with only what we have in 3.4.
>
> But it's hard.  Iterating through something asynchronously?  Write a
> 'while True' loop.  Instead of 1 line you now have 5 or 6.  Want to
> commit your database transaction?  Instead of 'async with' you will
> write 'try..except..finally' block, with a very high probability to
> introduce a bug, because you don't rollback or commit properly or
> propagate exception.
I don't see why you can't do transactions using a 'with' statement.
>
>> 1. Make a normal function into a generator or coroutine. This can be
>> done with a decorator.
>
> https://www.python.org/dev/peps/pep-0492/#rationale-and-goals
states that """
it is not possible to natively define a coroutine which has no yield or
yield from statement
"""
which is just not true.

> https://www.python.org/dev/peps/pep-0492/#debugging-features
Requires the addition of the CO_COROUTINE flag, not any new keywords.

> https://www.python.org/dev/peps/pep-0492/#importance-of-async-keyword
Seems to be repeating the above.
>
>> 2. Support a parallel set of special methods starting with 'a' or
>> 'async'. Why not just use the current set of special methods?
>
> Because you can't reuse them.
>
>
https://www.python.org/dev/peps/pep-0492/#why-not-reuse-existing-for-and-with-statements
Which seems back to front. The argument is that existing syntax
constructs cannot be made to work with asynchronous objects. Why not
make the asynchronous objects work with the existing syntax?

>
>
https://www.python.org/dev/peps/pep-0492/#why-not-reuse-existing-magic-names
The argument here relies on the validity of the previous points.
>
>
>> 3. "await". "await" is an operator that takes one argument and
>> produces a single result, without altering flow control and can thus
>> be replaced by an function.
>
> It can't be replaced by a function. Only if you use greenlets or
> Stackless Python.
Why not? The implementation of await is here:
https://github.com/python/cpython/compare/master...1st1:await#diff-23c87bfada1d01335a3019b9321502a0R642
which clearly could be made into a function.
>
>> 4. Asynchronous with statement. The PEP lists the equivalent as "with
>> (yield from xxx)" which doesn't seem so bad.
>
> There is no equivalent to 'async with'. "with (yield from xxx)" only
> allows you to suspend execution
> in __enter__ (and it's not actually in __enter__, but in a coroutine
> that returns a context manager).
>
>
https://www.python.org/dev/peps/pep-0492/#asynchronous-context-managers-and-async-with
> see "New Syntax" section to see what 'async with' is equivalent too.
Which, by comparing with PEP 343, can be translated as:
     with expr as e:
         e = await(e)
         ...
>
>>
>> Please don't add unnecessary new syntax.
>
>
> It is necessary.
This isn't an argument, it's just contradiction ;)

  Perhaps you haven't spent a lot of time maintaining
> huge code-bases developed with frameworks like asyncio, so I understand
> why it does look unnecessary to you.
This is a good reason for clarifying the distinction between 'normal'
generators and coroutines. It is not, IMO, justification for burdening
the language (and everyone porting Python 2 code) with extra syntax.

 How is it a burden for people porting Python 2 code? Because they won't
get to name anything 'async' just like anyone supporting older Python 3
versions? Otherwise I don't see how it is of any consequence to people
maintaining 2/3 code as it will just be another thing they can't use until
they drop Python 2 support.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150426/7976648f/attachment.html>