<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sat, Oct 22, 2016 at 8:22 PM, Nick Coghlan <span dir="ltr"><<a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>></span> wrote:<br><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Pondering this overnight, I realised there's a case where folks using<br>
Python primarily as a scripting language can still run into many of<br>
the resource management problems that arise in larger applications:<br>
IPython notebooks</blockquote><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">This is likely mitigated in practice *today* by IPython users mostly<br>
being on CPython for access to the Scientific Python stack, </blockquote><div><br></div><div>sure -- though there is no reason that Jupyter notebooks aren't really useful to all sort of non-data-crunching tasks. It's just that that's the community it was born in.</div><div><br></div><div>I can imagine they would be great for database exploration/management, for instance.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Chris, would you be open to trying a thought experiment with some of</blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
your students looking at ways to introduce function-scoped<br>
deterministic resource management *before* introducing with<br>
statements?</blockquote><div><br></div><div>At first thought, talking about this seems like it would just confuse newbies even MORE. Most of my students really want simple examples they can copy and then change for their specific use case.</div><div><br></div><div>But I do have some pretty experienced developers (new to Python, but not programming) in my classes, too, that I might be able to bring this up with.</div><div><br></div><div> # Cleaned up whenever the interpreter gets around to cleaning up</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
the function locals<br>
def readlines_with_default_<wbr>resource_management(fname):<br>
return open(fname).readlines()<br>
<br>
# Cleaned up on function exit, even if the locals are still<br>
referenced from an exception traceback<br>
# or the interpreter implementation doesn't use a reference counting GC<br>
from local_resources import function_resource<br>
<br>
def readlines_with_declarative_<wbr>cleanup(fname):<br>
return function_resource(open(fname))<wbr>.readlines()<br>
<br>
# Cleaned up at the end of the with statement<br>
def readlines_with_imperative_<wbr>cleanup(fname):<br>
with open(fname) as f:<br>
return f.readlines()<br>
<br>
The idea here is to change the requirement for new developers from<br>
"telling the interpreter what to *do*" (which is the situation we have<br>
for context managers) to "telling the interpreter what we *want*"<br>
(which is for it to link a managed resource with the lifecycle of the<br>
currently running function call, regardless of interpreter<br>
implementation details)<br></blockquote><div><br></div><div>I can see that, but I'm not sure newbies will -- it either case, you have to think about what you want -- which is the complexity I'm trying to avoid at this stage. Until much later, when I get into weak references, I can pretty much tell people that python will take care of itself with regards to resource management.</div><div><br></div><div>That's what context mangers are for, in fact. YOU can use:</div><div><br></div><div>with open(...) as infile:</div><div> .....</div><div><br></div><div>Without needing to know what actually has to be "cleaned up" about a file. In the case of files, it's a close() call, simple enough (in the absence of Exceptions...), but with a database connection or something, it could be a lot more complex, and it's nice to know that it will simply be taken care of for you by the context manager.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The big refactoring benefit that this feature would offer over with<br>
statements is that it doesn't require a structural change to the code<br>
- it's just wrapping an existing expression in a new function call<br>
that says "clean this up promptly when the function terminates, even<br>
if it's still part of a reference cycle, or we're not using a<br>
reference counting GC".</blockquote><div><br></div><div>hmm -- that would be simpler in one sense, but wouldn't it require a new function to be defined for everything you might want to do this with? rather than the same "with" syntax for everything?</div><div><br></div><div>-CHB</div><div><br></div><div><br></div></div><br clear="all"><div><br></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>