Paul,
On 2015-04-26 7:32 PM, Paul Sokolovsky wrote:
Hello,
On Sun, 26 Apr 2015 18:49:43 -0400
Yury Selivanov <yselivanov...@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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
