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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4