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

[Yury Selivanov]

Paul,

On 2015-04-26 7:32 PM, Paul Sokolovsky wrote:
> Hello,
>
> On Sun, 26 Apr 2015 18:49:43 -0400
> Yury Selivanov <yselivanov.ml at gmail.com> wrote:
>
> []
>
>>>>> - 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.
> So, again to make sure I (and hopefully other folks) understand it
> right. You say "it's perfectly normal for context managers in python to
> return any object from their __enter__". That's true, but we talk about
> async context managers. There're no such at all, they yet need to be
> written. And whoever writes them, would need to return from __enter__
> awaitable, because that's the requirement for an async context manager,
> and it is error to return something else.
>
> Then, is the only logic for proposing __aenter__ is to reinsure against
> a situation that someone starts to write async context manager, forgets
> that they write async context manager, and make an __enter__ method
> there.

It's to make sure that it's impossible to accidentally use
existing regular context manager that returns a future object
from its __enter__ / __exit__ (nobody prohibits you to return a
future object from __exit__, although it's pointless) in an
'async with' block.

I really don't understand the desire to reuse existing magic
methods.  Even if it was decided to reuse them, it wouldn't
even simplify the implementation in CPython; the code there
is already DRY (I don't re-implement opcodes for 'with'
statement; I reuse them).

> Then your implementation will announce that "async context
> manager lacks __aenter__", whereas "my" approach would announce
> "Async's manager __enter__ did not return awaitable value".
>
> Again, is that the distinction you're shooting for, or do I miss
> something?
>
> []
>
>> Anyways, I really doubt that you can convince anyone to
>> reuse existing dunder methods for async stuff.
> Yeah, but it would be nice to understand why "everyone" and "so easily"
> agrees to them, after pretty thorough discussion of other aspects.
>
NP :)  FWIW, I wasn't trying to dodge the question, but
rather stressing that the DRY argument is weak.

And thanks for pointing out that this isn't covered
in the PEP in enough detail. I'll update the PEP soon.

Thanks!
Yury