Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #108252

Re: A fun python CLI program for all to enjoy!

Show key headers only | View raw

On Fri, May 6, 2016, at 04:58 PM, DFS wrote:
> Improper f.close didn't seem to affect any of the files my program wrote 
> - and I checked a lot of them when I was writing the code.

To be clear, its not an "improper" f.close. That command is simply not
closing the file. Period. "f.close" is how you get the 'close' function
from the 'f' object, and then... you do nothing with it.

If you removed "f.close" entirely, you'd get the exact same behavior as
you have now. The "f.close" does nothing.

That said, in CPython semantics, closing a file explicitly is often not
required. CPython is reference-counted. Once the references to an object
reaches 0, CPython deletes the object. This is an implementation detail
of the CPython and not a guarantee of the Python language itself, which
is why explicit close calls are preferred.

So while 'f.close' does nothing, CPython might be closing the file
*anyways*, and it might work... but that 'might' is hard to reason about
without a deeper understanding, so using explicit closing mechanics
(either via f.close() or with or something else) is strongly
recommended. 

For example, if you were to do:

for item in sequence:
    f = open(item, 'wb')
    f.write("blah")

It probably works fine. The first time through, 'f' is bound to a file
object, and you write to it. The second time through, 'f' is bound to a
*new file object*, and the original file object now has 0 references, so
is automatically deleted. 

The last sequence through, f is not closed: the 'for loop' is not a
scope which deletes its internal name bindings when its done. So that
'f' will likely remain open until the very end of the current function,
which may be an issue for you.

Implicit closing actually works in a large number of situations in
CPython, but it isn't a good thing to rely on. It only works in simple
operations where you aren't accidentally storing a reference somewhere
else. You have to keep track of the references in your head to make sure
things will get closed at proper times.

The 'with' statement clearly defines when resources should be closed, so
its preferred (As I see you've adopted from other responses). But its
also needed in other Python implementations which might not follow
CPython's reference counting scheme.

I'm not giving further feedback because MRAB caught everything I thought
was an issue.

-- 
Stephen Hansen
  m e @ i x o k a i . i o

Back to comp.lang.python | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

A fun python CLI program for all to enjoy! DFS <nospam@dfs.com> - 2016-05-06 15:10 -0400
  Re: A fun python CLI program for all to enjoy! MRAB <python@mrabarnett.plus.com> - 2016-05-06 21:30 +0100
    Re: A fun python CLI program for all to enjoy! DFS <nospam@dfs.com> - 2016-05-06 19:12 -0400
      Re: A fun python CLI program for all to enjoy! Ethan Furman <ethan@stoneleaf.us> - 2016-05-06 16:29 -0700
        Re: A fun python CLI program for all to enjoy! DFS <nospam@dfs.com> - 2016-05-06 19:58 -0400
          Re: A fun python CLI program for all to enjoy! MRAB <python@mrabarnett.plus.com> - 2016-05-07 01:38 +0100
          Re: A fun python CLI program for all to enjoy! Stephen Hansen <me+python@ixokai.io> - 2016-05-06 23:03 -0700
          Re: A fun python CLI program for all to enjoy! Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2016-05-07 18:24 +1200
            Re: A fun python CLI program for all to enjoy! alister <alister.ware@ntlworld.com> - 2016-05-07 08:51 +0000
  Re: A fun python CLI program for all to enjoy! Peter Otten <__peter__@web.de> - 2016-05-07 15:59 +0200

csiph-web