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

[Paul Sokolovsky]

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