<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content="text/html; charset=utf-8" http-equiv=Content-Type><!-- flashmail style begin -->
<STYLE type=text/css>
body {border-width:0;margin:0}
img {border:0;margin:0;padding:0}
</STYLE>
<BASE target=_blank><!-- flashmail style end -->
<META name=GENERATOR content="MSHTML 11.00.10570.1001"></HEAD>
<BODY 
style="BORDER-LEFT-WIDTH: 0px; FONT-SIZE: 10.5pt; FONT-FAMILY: 微软雅黑; BORDER-RIGHT-WIDTH: 0px; BORDER-BOTTOM-WIDTH: 0px; COLOR: #000000; MARGIN: 12px; LINE-HEIGHT: 1.5; BORDER-TOP-WIDTH: 0px" 
marginheight="0" marginwidth="0">
<DIV>
<DIV>Well the code don't appear to be broken, in fact they have been 
working well for serveral months with PyPy, it only means the design is broken - 
there are chances that iterators are not closed correctly in certain 
circumstances which leads to unpredictable behaviors. It might not be critical 
for small scripts but may be quite critical for services that must keep 
running for a long time, which is what PyPy is for. Files may not be the 
most critical problem, the real problem is LOCK - when you use <EM>with</EM> on 
a lock, there are chances that it never unlocks.</DIV>
<DIV> </DIV>
<DIV>As far as I know quite a lot of softwares use generators on network 
programmings because it is convenient to process the callbacks with 
generators, and it is not so unusual to "call" another generator method or 
recurse on itself. When the connection is suddenly shutdown, the connection 
manager closes the generator - but not the generators called inside.</DIV>
<DIV>Python 3 is using this as the standard programming model of asyncio, it may 
also suffer but not that much, because <EM>yield from</EM> seems to close the 
iterator automatically because it reraises the exception inside.</DIV></DIV>
<DIV> </DIV>
<DIV style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana; COLOR: #c0c0c0" 
align=left>2016-10-24 
<HR id=SignNameHR 
style="BORDER-TOP: #c0c0c0 1px solid; HEIGHT: 1px; BORDER-RIGHT: 0px; WIDTH: 122px; BORDER-BOTTOM: 0px; BORDER-LEFT: 0px" 
align=left>
<SPAN id=_FlashSignName>hubo</SPAN> </DIV>
<HR 
style="BORDER-TOP: #c0c0c0 1px solid; HEIGHT: 1px; BORDER-RIGHT: 0px; BORDER-BOTTOM: 0px; BORDER-LEFT: 0px">

<BLOCKQUOTE id=ntes-flashmail-quote 
style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana; PADDING-LEFT: 0px; MARGIN-LEFT: 0px">
  <DIV><STRONG>发件人:</STRONG>Steven D'Aprano <steve@pearwood.info></DIV>
  <DIV><STRONG>发送时间:</STRONG>2016-10-22 07:13</DIV>
  <DIV><STRONG>主题:</STRONG>Re: [pypy-dev] RFC: draft idea for making for loops 
  automatically close iterators</DIV>
  <DIV><STRONG>收件人:</STRONG>"pypy-dev"<pypy-dev@python.org></DIV>
  <DIV><STRONG>抄送:</STRONG></DIV>
  <DIV> </DIV>
  <DIV>
  <DIV>On Fri, Oct 21, 2016 at 10:13:45PM +0800, hubo wrote: </DIV>
  <DIV> </DIV>
  <DIV>> Well I'm really shocked to find out what I thought was a "automatic  </DIV>
  <DIV>> close" is really the ref-couting GC of CPython, means that a lot of my  </DIV>
  <DIV>> code breaks in PyPy...  </DIV>
  <DIV> </DIV>
  <DIV>But does it really? </DIV>
  <DIV> </DIV>
  <DIV>If you've run your code in PyPy, and it obviously, clearly breaks, then  </DIV>
  <DIV>why are you so shocked? You should have already known this. (Unless this  </DIV>
  <DIV>is your first time running your code under PyPy.) </DIV>
  <DIV> </DIV>
  <DIV>But if your code runs under PyPy, with no crashes, no exceptions, no  </DIV>
  <DIV>failures caused by running out of file descriptors... then you can't  </DIV>
  <DIV>really say your code is broken. What does it matter if your application  </DIV>
  <DIV>doesn't close the files until exit, if you only open three files and the  </DIV>
  <DIV>application never runs for more than two seconds? </DIV>
  <DIV> </DIV>
  <DIV>I'd like to get a good idea of how often this is an actual problem,  </DIV>
  <DIV>causing scripts and applications to fail when run in PyPy. Actual  </DIV>
  <DIV>failures, not just wasting a file descriptor or three. </DIV>
  <DIV> </DIV>
  <DIV> </DIV>
  <DIV> </DIV>
  <DIV>> I'm wondering since a ref-counting GC implemention is not possible for  </DIV>
  <DIV>> PyPy, is it possible to hack on the for loop to make it "try to"  </DIV>
  <DIV>> collect the generator? That may really save a lot of lives. </DIV>
  <DIV> </DIV>
  <DIV>Saving lives? That's a bit of an exaggeration, isn't it? </DIV>
  <DIV> </DIV>
  <DIV>There is a big discussion going on over on the Python-Ideas mailing  </DIV>
  <DIV>list, and exaggerated, over-the-top responses aren't going to help this  </DIV>
  <DIV>proposal's case. Already people have said this issue is only a problem  </DIV>
  <DIV>for PyPy, so it's PyPy's problem to fix. </DIV>
  <DIV> </DIV>
  <DIV> </DIV>
  <DIV> </DIV>
  <DIV>--  </DIV>
  <DIV>Steve </DIV>
  <DIV>_______________________________________________ </DIV>
  <DIV>pypy-dev mailing list </DIV>
  <DIV>pypy-dev@python.org </DIV>
  <DIV>https://mail.python.org/mailman/listinfo/pypy-dev </DIV>
  <DIV> </DIV></DIV></BLOCKQUOTE></BODY></HTML>