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

Yury Selivanov yselivanov.ml at gmail.com
Mon Apr 27 00:49:43 CEST 2015

Paul,

On 2015-04-26 6:25 PM, Paul Sokolovsky wrote:

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.

That's debatable. It might be useful to create hybrid objects that can work in 'with (yield from lock)' and 'async with lock' statements.

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

I'll update the PEP.

The argument shouldn't be that it's confusing, the argument is that aenter returns an 'awaitable', which is either a coroutine-object or a future.

You can't reuse enter, because you'd break backwards compatibility -- it's perfectly normal for context managers in python to return any object from their enter. If we assign some special meaning to futures -- we'll break existing code.

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

Async with implies using YIELD_FROM opcodes. If you want to make regular with statements compatible you'd need to add a lot of opcodes that will at runtime make a decision whether to use YIELD_FROM or not.

The other point is that you can't just randomly start using YIELD_FROM, you can only do so from generators/coroutines.

>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. I'd say that a lot of terrible mistakes has happened in software development precisely because someone followed DRY religiously. Following it here will break backwards compatibility and/or make it harder to understand what is actually going on with your code.

You argue that this will make coroutine writing simple. But coroutines are part of the language, and duplicating notions makes language more complex/complicated. Again, it makes reasoning about your code simpler. That what matters.

Anyways, I really doubt that you can convince anyone to reuse existing dunder methods for async stuff.

Thanks, Yury

More information about the Python-Dev mailing list