Nick Coghlan <ncogh...@gmail.com> added the comment:
I agree we need to add something here to better support the idiom where the
"close" and "delete" operations on a NamedTemporaryFile are decoupled without
the delete becoming a completely independent call to os.unlink().
I agree with RDM's proposal in issue 14514 that the replacement should be
"delete on __exit__ but not on close". As with generator context managers, I'd
also add in the "last ditch" cleanup behaviour in __del__.
Converting the issue to a feature request for 3.3 - there's no bug here, just
an interaction with Windows that makes the existing behavioural options
inconvenient.
After all, you can currently get deterministic cleanup (with a __del__
fallback) via:
@contextmanager
def named_temp(name):
f = NamedTemporaryFile(name, delete=False)
try:
yield f
finally:
try:
os.unlink(name)
except OSError:
pass
You need to be careful to make sure you keep the CM alive (or it will delete
the file behind your back), but the idiom RDM described in the other issues
handles that for you:
with named_temp(fname) as f:
data = "Data\n"
f.write(data)
f.close() # Windows compatibility
with open(fname) as f:
self.assertEqual(f.read(), data)
As far as the API goes, I'm inclined to make a CM with the above behavour
available as a new class method on NamedTemporaryFile:
with NamedTemporaryFile.delete_after(fname) as f:
# As per the workaround
----------
title: NamedTemporaryFile unusable under Windows -> tempfile.NamedTemporaryFile
not particularly useful on Windows
type: behavior -> enhancement
versions: -Python 2.7, Python 3.2
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue14243>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
