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

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.

Cheers,
Mark.
_______________________________________________
Python-Dev mailing list
Pyth...@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: https://mail.python.org/mailman/options/python-dev/python-dev-ml%40activestate.com