Well, with scope and try...finally... are really important in asynchronized programming, so I'm afraid we cannot just drop it. There isn't a replacement for an iterator to safely dispose some resources; and now we know that EVEN with and finally are not really safe...
It turns out that what we love most and trust most harm us most :( 2016-10-24 hubo 发件人：Nathaniel Smith <n...@pobox.com> 发送时间：2016-10-24 15:24 主题：Re: [pypy-dev] RFC: draft idea for making for loops automatically close iterators 收件人："Armin Rigo"<armin.r...@gmail.com> 抄送："hubo"<h...@jiedaibao.com>,"PyPy Developer Mailing List"<pypy-dev@python.org> On Sun, Oct 23, 2016 at 11:42 PM, Armin Rigo <armin.r...@gmail.com> wrote: > Hi, > > On 24 October 2016 at 06:03, hubo <h...@jiedaibao.com> wrote: >> long time, which is what PyPy is for. Files may not be the most critical >> problem, the real problem is LOCK - when you use with on a lock, there are >> chances that it never unlocks. > > Bah. I would say that it makes the whole "with" statement pointless > in case you're using "await" somewhere inside it. In my own honest > opinion it should not be permitted to do that at all---like, it should > be a SyntaxError to use "await" inside a "with". (This opinion is > based on a very vague understanding of async/await in the first place, > so please take it with a grain of salt.) Interesting historical tidbit: until PEP 342, it actually was a syntax error to yield inside try, or at least inside try/finally. Actually relevant modern answer: 'await' inside 'with' turns out to be OK, because async functions are always run by some supervisor (like an event loop), and so the solution is that the supervisor guarantees as part of its semantics that it will always run async functions to completion. (You're right that this isn't obvious though -- it took very confused thread on the async-sig mailing list to recognize the problem and solution.) Since event loops are already rocket science and you only need one of them, requiring them to take some care here isn't a big deal. The problem with (async) generators is that everyone who uses them also has to make some similar guarantee (i.e., they must be run to completion, either by exhausting them or calling .close()), but they get used all over the place in random user code, and it's not reasonable to ask users to figure this out every time they write a 'for' loop. -n -- Nathaniel J. Smith -- https://vorpus.org
_______________________________________________ pypy-dev mailing list pypy-dev@python.org https://mail.python.org/mailman/listinfo/pypy-dev
