[Python-ideas] Implementation of shutil.move
Devin Jeanpierre
jeanpierreda at gmail.com
Mon Aug 15 15:41:05 CEST 2011
> 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.
The normal open() always did seem a bit weak, and this is probably the
biggest use-case that it doesn't cover.
+1
> 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?
Well, that's basically what I was getting at. I don't like the idea of
silently falling back to the unsafe thing one bit. It wouldn't be so
bad to have something that tries to do it without any race conditions
etc., and raises an exception if this isn't possible.
Devin
On Mon, Aug 15, 2011 at 8:20 AM, David Townshend <aquavitae69 at gmail.com> wrote:
>
>
> 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?
More information about the Python-ideas
mailing list