[Python-ideas] Implementation of shutil.move

David Townshend aquavitae69 at gmail.com
Mon Aug 15 14:20:23 CEST 2011


On Mon, Aug 15, 2011 at 1:42 PM, Devin Jeanpierre <jeanpierreda at gmail.com>wrote:

> > open(), in my opinon, already behaves as it should.
>
> open(..., 'w') doesn't, it overwrites the target. For copying an
> individual file, you'd want os.open(..., O_EXCL | O_CREAT), which is a
> cross-platform, race-condition-free way of creating and writing to a
> single file provided it didn't exist before.
>
> Good point.  Perhaps the best way of improving this would be to add a 'c'
mode to the builtin open() for creating new files, so that typical usage
would be open(file, 'cw').  Or maybe 'c' should imply 'w', since there seems
little point in creating a new file read-only.


> > From what I've read, there are several ways of ensuring that these
> functions
> > fail if destination exists depending on the platform and filesystem, but
> > there is no uniform way to do it. One approach would be to try all
> possible
> > methods and hope that at least one works, with a simple "if
> os.exists(dst):
> > fail" fallback.  The documentation would state that "An exception occurs
> if
> > the destination exists.  This check is done is as safe a way possible to
> > avoid race conditions where the system supports it."
>
> There are two attitudes to take when using the don't-overwrite argument:
>
> 1. User cares about safety and race conditions, is glad that this
> function tries to be safe.
>
> 2. User doesn't care about safety or race conditions, as User doesn't
> have shell scripts creating files at inconvenient times and tempting
> fate.
>
> In case 1, having it silently revert to the unsafe version is very
> bad, and potentially damaging. In case 2, the user doesn't care about
> the safe version. In fact, User 2 is probably using os.path.exists
> already.
>
> If it can't do things safely, it shouldn't do them at all.


So we provide an alternate safe implementation, which may not work on all
systems? And it will be up to the user to decide whether to fall back to the
unsafe functions?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20110815/bb0728ba/attachment.html>


More information about the Python-ideas mailing list