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

Paul Sokolovsky pmiscml at gmail.com
Mon Apr 27 01:32:06 CEST 2015

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

More information about the Python-Dev mailing list