Closing a file

[David Bolen]

"Duncan Smith" <buzzard at urubu.freeserve.co.uk> writes:

> I am using PythonWin.  I do try to close the file with outputfile.close()
> after the second 'if'.  I don't understand why it apparently doesn't work.
> ie. I want to open a file and write to it on the first iteration (which it
> does), write to it on subsequent iterations (which it does), and close it
> after a certain number of iterations (which it doesn't).  Thanks for your
> help, but I'm afraid I'm still stuck.

It might help to see a little more of the application, because I'm not
sure the excerpt you included can even execute your close operation
without raising a NameError.  So if you aren't getting the exception,
then perhaps that portion of the code isn't even running when you
think it is?

If you look at your function definition (I'm assuming it's a method of
some class you didn't include in your post), you have the following:

    def acceptsim(self, cost, n):
        t = 10000.0 / n
        if self.cost == 0:
            outputfile = open('simresults.txt', 'w')
            sys.stdout = outputfile
            self.cost = DJT.totalcost(self)
            self.low_cost = self.cost
            self.low_ordering = self.ordering[:]
        if n > 900000:
            outputfile.close()
            return 'stop'

        (...)

Now, here's one problem - your use of outputfile makes it a local
variable to the acceptsim method.  It's not an instance variable, so
it won't be preserved from method invocation to method invocation.

So unless you execute this function where both self.cost==0 and
n>900000, your use of outputfile.close() will refer to outputfile when
it doesn't exist (never having been assigned to reference anything).
That doesn't affect the other output of the function since you also
assign the reference to the file to sys.stdout which is preserved
across calls to your method.

As to why the file still appears to be opened/locked from other
applications, the prior response about sys.stdout still referencing
the file is a good possibility, especially given that it doesn't
appear likely that your outputfile.close() is executing and/or even if
it did, it would be trying to close something different since it won't
still reference the same file.

So one thought would be to just make outputfile an instance variable
(self.outputfile) which will preserve its value.  I would also verify
that your n>90000 clause is actually triggering.  You might use
sys.stderr.write() to write any debugging output to the console since
sys.stdout is redirected.

But I'd also look at how you are handling your file reference.  If
you're going to use outputfile to close the file, you want to be
careful not to leave sys.stdout pointed to it after the close.  If you
need it to work as sys.stdout (e.g., rather than just using
outputfile.write in the other portions of your method), then I'd save
the old sys.stdout in an instance variable, and restore it to
sys.stdout after you close the file.

There's also a small chance that once you have assigned to sys.stdout
that Pythonwin is saving a reference to that somewhere which also
contributes a reference to the open file.  But closing the file
explicitly should still take care of the Windows sharing issues,
although I suppose that might affect Pythonwin's ability to restore
things.  I would worry too much about that until you work out the
actual handling of the outputfile file reference though.

--
-- David
-- 
/-----------------------------------------------------------------------\
 \               David Bolen            \   E-mail: db3l at fitlinxx.com  /
  |             FitLinxx, Inc.            \  Phone: (203) 708-5192    |
 /  860 Canal Street, Stamford, CT  06902   \  Fax: (203) 316-5150     \
\-----------------------------------------------------------------------/