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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4