Author dlenski
Recipients brian.curtin, dabrahams, dlenski, eric.araujo, eric.smith, jaraco, ncoghlan, pitrou, r.david.murray, tim.golden
Date 2012-06-30.05:45:36
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1341035137.77.0.664208977189.issue14243@psf.upfronthosting.co.za>
In-reply-to
Content
Tim Golden,
My preferred solution would be to replace the binary delete argument of the current NamedTemporaryFile implementation with finer-grained options:
   delete=False         # don't delete
   delete=True          # delete after file closed, current behavior
   delete=AFTER_CLOSE   # delete after file closed
   delete=AFTER_CM_EXIT # delete after context manager exits
   delete=AFTER_CM_EXIT_NO_EXCEPTION # delete after CM exit, unless this is due to an exception

I have implemented a Windows-friendly solution to the latter case using Nick Coghlan's code.  My version does not delete the file until the context manager exits, and *if* the context manager exits due to an exception it leaves the file in place and reports its location, to aid me in debugging.
History
Date User Action Args
2012-06-30 05:45:37dlenskisetrecipients: + dlenski, jaraco, ncoghlan, pitrou, eric.smith, tim.golden, eric.araujo, r.david.murray, brian.curtin, dabrahams
2012-06-30 05:45:37dlenskisetmessageid: <1341035137.77.0.664208977189.issue14243@psf.upfronthosting.co.za>
2012-06-30 05:45:37dlenskilinkissue14243 messages
2012-06-30 05:45:36dlenskicreate