On 4/29/2008 2:18 PM, Nick Coghlan wrote:
Same here. In fact, is there a good reason to have mkstemp() return the
> fd (except backward compatibility)?
Except for backwards compatibility: is there a good reason to keep
os.mkstemp at all?
Greg Ewing's use-case is one I've also had at times - ie. as a
convenience function for creating a "somewhat temporary" file that is
randomly named, but persists beyond the closing of the file. If the
function doesn't stay in os it doesn't make any difference to me
though :-)
As of 2.6, Greg's use case is addressed by the new 'delete' parameter on
tempfile.NamedTemporaryFile.
Then I personally don't have any objection to the removal of os.mkstemp.
Since we're at it, a common pattern I use is to create temporary file to
atomically replace files: I create a named temporary file in the same
directory of the file I want to replace; write data into it; close it;
and move it (POSIX "move": rename with silent overwrite) to the
destination file. AFAIK, this is allows an atomic file replacemente on
most filesystems.
I believe this is a common useful pattern that could be handled in
module tmpfile (especially since the final "rename" step requires a
little care to be truly multiplatform).
--
Giovanni Bajo
Develer S.r.l.
http://www.develer.com
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
