Originally filed by Robert Schroll as:

 http://www.reinteract.org/trac/ticket/91

First reported on the mailing list:

  http://groups.google.com/group/reinteract/browse_thread/thread/2e7d5a7e18695262#

Attempting to write to a file from the top level of a notebook gives

ValueError: I/O operation on closed file

The problem seems to be that Reinteract thinks that f.write('blah') may modifiy f, so it makes a copy of f before execution. A copy of an open file object, however, is a closed file object, which leads to this error. Assigning this statement to another variable (g = f.write('blah')) gets around this problem.

Perhaps file objects should not be tracked by Reinteract's versioning system. It won't be able to undo the actions to the files in any event. A better work-around in the meantime is to enclose all of the file operations in a block, e.g.

try:
    f = file('temp.txt', 'w')
    f.write('Blah')
finally:
    f.close()

Bonus related bug: Sometimes f = file('temp.txt', 'w'); g = f.write('Blah'); f.close() will not actually modify temp.txt, despite not throwing any errors. I believe this is because a copy of f is made before f.close(), and it is this copy (an already closed file object) that is closed, leaving the original object open, and thus potentially not flushed. 

11/07/09 20:29:56 changed by otaylor
====================================

Copying out an interesting part of my reply on that mailing list thread:

    I think the long-term solution here is to have some way of "annotating" standard methods, so Reinteract would know:

  m = re.search("b+", "abbbb")
  m.group(0) # Not a mutation, no need to copy
  f = file('temp.txt', 'w')
  f.write('Hi!\n') # A mutation, can't copy, need to re-execute from the point f was initially assigned