Paul, On 2015-04-26 6:25 PM, Paul Sokolovsky wrote: > Ok, so here're 3 points this link gives, with my concerns/questions: > >> >An alternative idea about new asynchronous iterators and context >> >managers was to reuse existing magic methods, by adding an async >> >keyword to their declarations: >> >[But:] >> > - it would not be possible to create an object that works in both >> >with and async with statements; > Yes, and I would say, for good. Behavior of sync and async code is > different enough to warrant separate classes (if not libraries!) to > implement each paradigm. What if, in otherwise async code, someone will > miss "async" in "async with" and call sync version of context manager? > So, losing ability stated above isn't big practical loss. That's debatable. It might be useful to create hybrid objects that can work in 'with (yield from lock)' and 'async with lock' statements. > > >> >- 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. > >> >and would require some implicit magic behind the scenes in the >> >interpreter; > Interpreter already does a lot of "implicit magic". Can you please > elaborate what exactly would need to be done? Async with implies using YIELD_FROM opcodes. If you want to make regular with statements compatible you'd need to add a lot of opcodes that will at runtime make a decision whether to use YIELD_FROM or not. The other point is that you can't just randomly start using YIELD_FROM, you can only do so from generators/coroutines. > >> >one of the main points of this proposal is to make coroutines as >> >simple and foolproof as possible. > And it's possible to agree that "to separate notions, create a > dichotomy" is a simple principle on its own. But just taking bunch of > stuff - special methods, exceptions - and duplicating it is a bloat a > violates another principle - DRY. I'd say that a lot of terrible mistakes has happened in software development precisely because someone followed DRY religiously. Following it here will break backwards compatibility and/or make it harder to understand what is actually going on with your code. > You argue that this will make > coroutine writing simple. But coroutines are part of the language, and > duplicating notions makes language more complex/complicated. Again, it makes reasoning about your code simpler. That what matters. Anyways, I really doubt that you can convince anyone to reuse existing dunder methods for async stuff. 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