[pypy-dev] RFC: draft idea for making for loops automatically close iterators

[hubo]

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 <njs at pobox.com>
发送时间：2016-10-24 15:24
主题：Re: [pypy-dev] RFC: draft idea for making for loops automatically close iterators
收件人："Armin Rigo"<armin.rigo at gmail.com>
抄送："hubo"<hubo at jiedaibao.com>,"PyPy Developer Mailing List"<pypy-dev at python.org>

On Sun, Oct 23, 2016 at 11:42 PM, Armin Rigo <armin.rigo at gmail.com> wrote: 
> Hi, 
> 
> On 24 October 2016 at 06:03, hubo <hubo at 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 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20161024/6e2a7b8e/attachment.html>