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

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