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

[Paul Sokolovsky]

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

> Thanks,
> Yury



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