[Python-Dev] PEP 492: No new syntax is required (original) (raw)

Paul Sokolovsky pmiscml at gmail.com
Mon Apr 27 00:25:12 CEST 2015

Hello,

On Sun, 26 Apr 2015 16:40:03 -0400 Yury Selivanov <yselivanov.ml at gmail.com> 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:

Indeed, they are. It is the very basic counter-argument against this PEP is that everything it proposes is already doable. But the PEP makes very clear that the only reason it exists is to make coroutine programming easier and less error-prone.

However, given that there're questions even like that and you're great at keeping up discussion, I'd appreciate additional argumentation on:

> 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-magic-names

Ok, so here're 3 points this link gives, with my concerns/questions:

An alternative idea about new asynchronous iterators and context managers was to reuse existing magic methods, by adding an async keyword to their declarations:

[But:]

- it would not be possible to create an object that works in both with and async with statements;

Yes, and I would say, for good. Behavior of sync and async code is different enough to warrant separate classes (if not libraries!) to implement each paradigm. What if, in otherwise async code, someone will miss "async" in "async with" and call sync version of context manager? So, losing ability stated above isn't big practical loss.

- it would look confusing

Sorry, "async def enter" doesn't look more confusing than "aenter" (vs "enter").

and would require some implicit magic behind the scenes in the interpreter;

Interpreter already does a lot of "implicit magic". Can you please elaborate what exactly would need to be done?

one of the main points of this proposal is to make coroutines as simple and foolproof as possible.

And it's possible to agree that "to separate notions, create a dichotomy" is a simple principle on its own. But just taking bunch of stuff - special methods, exceptions - and duplicating it is a bloat a violates another principle - DRY. You argue that this will make coroutine writing simple. But coroutines are part of the language, and duplicating notions makes language more complex/complicated. Can you please argue that in this case it's worth duplicating hierarchies instead of reusing existing lower-level concepts, given that higher-level concepts are already distinguished well enough (async and await keywords separate "old" and "new" things very visibly).

-- Best regards, Paul mailto:pmiscml at gmail.com

More information about the Python-Dev mailing list