<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Oct 21, 2016 at 12:12 AM, Steven D'Aprano <span dir="ltr"><<a href="mailto:steve@pearwood.info" target="_blank">steve@pearwood.info</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Portability across Pythons... if all Pythons performed exactly the same,<br>
why would we need multiple implementations? The way I see it,<br>
non-deterministic cleanup is the cost you pay for a non-reference<br>
counting implementation, for those who care about the garbage collection<br>
implementation. (And yes, ref counting is garbage collection.)<br></blockquote><div><br></div><div>Hmm -- and yet "with" was added, and I an't imageine that its largest use-case is with ( ;-) ) open:</div><div><br></div><div>with open(filename, mode) as my_file:</div><div>    ....</div><div>    ....</div><div><br></div><div>And yet for years I happily counted on reference counting to close my files, and was particularly happy with:</div><div><br></div><div>data = open(filename, mode).read()</div><div><br></div><div>I really liked that that file got opened, read, and closed and cleaned up right off the bat.</div><div><br></div><div>And then context managers were introduced. And it seems to be there is a consensus in the Python community that we all should be using them when working on files, and I myself have finally started routinely using them, and teaching newbies to use them -- which is kind of a pain, 'cause I want to have them do basic file reading stuff before I explain what a "context manager" is.</div><div><br></div><div>Anyway, my point is that the broader Python community really has been pretty consistent about making it easy to write code that will work the same way (maybe not with the same performance) across python implementations. Ans specifically  with deterministic resource management.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On my system, I can open 1000+ files as a regular user. I can't even<br>
comprehend opening a tenth of that as an ordinary application, although<br>
I can imagine that if I were writing a server application things would<br>
be different. </blockquote><div><br></div><div>well, what you can image isn't really the point -- I've bumped into that darn open file limit in my work, which was not a server application (though it was some pretty serious number crunching...). And I'm sure I'm not alone. OK, to be fair that was a poorly designed library, not an issue with determinism of resource management (through designing the lib well WOULD depend on that)</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">But then I don't expect to write server applications in<br>
quite the same way as I do quick scripts or regular user applications.<br></blockquote><div><br></div><div>Though data analysts DO write "quick scripts" that might need to do things like access 100s of files...</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
So it seems to me that a leaked file handler or two normally shouldn't<br>
be a problem in practice. They'll be friend when the script or<br>
application closes, and in the meantime, you have hundreds more<br>
available. 90% of the time, using `with file` does exactly what we want,<br>
and the times it doesn't (because we're writing a generator that isn't<br>
closed promptly) 90% of those times it doesn't matter.</blockquote><div><br></div><div>that was the case with "with file" from the beginning -- particularly on cPython. And yet we all thought it was a great idea.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> So (it seems to<br>
me) that you're talking about changing the behaviour of for-loops to<br>
suit only a small proportion of cases: maybe 10% of 10%.<br></blockquote><div><br></div><div>I don't see what the big overhead is here. for loops would get a new feature, but it would only be used by the objects that chose to implement it. So no huge change.</div><div><br></div><div>-CHB</div><div><br></div><div><br></div></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><br>Christopher Barker, Ph.D.<br>Oceanographer<br><br>Emergency Response Division<br>NOAA/NOS/OR&R            (206) 526-6959   voice<br>7600 Sand Point Way NE   (206) 526-6329   fax<br>Seattle, WA  98115       (206) 526-6317   main reception<br><br><a href="mailto:Chris.Barker@noaa.gov" target="_blank">Chris.Barker@noaa.gov</a></div>
</div></div>