<div dir="ltr">Personally, I hadn't realised we had this problem in asyncio until now.<div><br></div><div>Does this problem happen in asyncio at all?  Or does asyncio somehow work around it by making sure to always explicitly destroy the frames of all coroutine objects, as long as someone waits on each task?<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 21 October 2016 at 16:08, Yury Selivanov <span dir="ltr"><<a href="mailto:yselivanov.ml@gmail.com" target="_blank">yselivanov.ml@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
<br>
On 2016-10-21 6:29 AM, Steven D'Aprano wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Wed, Oct 19, 2016 at 05:52:34PM -0400, Yury Selivanov wrote:<br>
</blockquote></span>
[..]<span class=""><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
With you proposal, to achieve the same (and make the code compatible<br>
with new for-loop semantics), users will have to implement both<br>
__iterclose__ and __del__.<br>
</blockquote>
As I ask above, couldn't we just inherit a default __(a)iterclose__ from<br>
object that looks like this?<br>
<br>
     def __iterclose__(self):<br>
         finalizer = getattr(type(self), '__del__', None)<br>
         if finalizer:<br>
             finalizer(self)<br>
<br>
<br>
I know it looks a bit funny for non-iterables to have an iterclose<br>
method, but they'll never actually be called.<br>
</blockquote>
<br></span>
No, we can't call __del__ from __iterclose__.  Otherwise we'd<br>
break even more code that this proposal already breaks:<br>
<br>
<br>
  for i in iter:<br>
     ...<br>
  iter.something()  # <- this would be call after iter.__del__()<br>
<br>
[..]<span class=""><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
As for the amount of good, this proposal originally came from PyPy. I<br>
expect that CPython users won't appreciate it as much as PyPy users, and<br>
Jython/IronPython users when they eventually support Python 3.x.<br>
</blockquote>
<br></span>
AFAIK the proposal came "for" PyPy, not "from".  And the<br>
issues Nathaniel tries to solve do also exist in CPython.  It's<br>
only a question if changing 'for' statement and iteration protocol<br>
is worth the trouble.<span class="HOEnZb"><font color="#888888"><br>
<br>
Yury</font></span><div class="HOEnZb"><div class="h5"><br>
______________________________<wbr>_________________<br>
Python-ideas mailing list<br>
<a href="mailto:Python-ideas@python.org" target="_blank">Python-ideas@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-ideas" rel="noreferrer" target="_blank">https://mail.python.org/mailma<wbr>n/listinfo/python-ideas</a><br>
Code of Conduct: <a href="http://python.org/psf/codeofconduct/" rel="noreferrer" target="_blank">http://python.org/psf/codeofco<wbr>nduct/</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Gustavo J. A. M. Carneiro<div>Gambit Research<br>"The universe is always one step beyond logic." -- Frank Herbert</div></div></div>
</div>