[Python-ideas] Add create mode to open()
Devin Jeanpierre
jeanpierreda at gmail.com
Wed Aug 17 05:43:56 CEST 2011
> Agreed. Also I think that in most cases the right thing to do is to
> quietly overwrite the file. If you're implementing a UI where you want
> look-before-you-leap, the app should code an explicit test so it can
> issue a proper error message (the exception will not be fun for the
> user :-).
The explicit test being "if not os.path.exists(pth)"? That has a race condition.
LBYL is impossible here without a race condition, in fact, because the
situation can change between looking and leaping. An exception, or
else return code, is the only way. These can be checked for after the
fact.
I'd also point out that for those that don't want race conditions,
Python is discouraging. The correct incantation involves two
undocumented constants, plus a unique and rarely used way of opening
files that involves unix file descriptors.
Devin
On Tue, Aug 16, 2011 at 6:43 PM, Guido van Rossum <guido at python.org> wrote:
> On Tue, Aug 16, 2011 at 2:26 PM, Benjamin Peterson <benjamin at python.org> wrote:
>> David Townshend <aquavitae69 at ...> writes:
>>
>>>
>>>
>>> This idea was proposed in the discussion on shutil.move, but I thought it
>> would be worth posting separately to avoid confusing the discussion.
>>>
>>> The idea is to add a create mode ('c') to the builtin open() function, which
>> will have the same effect as os.open(file, os.O_EXCL|os.O_CREAT). I have added
>> an issue (http://bugs.python.org/issue12760) for this, including a patch.
>>
>> I am -1 because
>>
>> - Possibly not portable or at least subject to implementations of
>> varying quality.
>> - No precedence in other languages or fopen() for that matter.
>> - It's not hard to use os.fdopen().
>
> Agreed. Also I think that in most cases the right thing to do is to
> quietly overwrite the file. If you're implementing a UI where you want
> look-before-you-leap, the app should code an explicit test so it can
> issue a proper error message (the exception will not be fun for the
> user :-).
>
> --
> --Guido van Rossum (python.org/~guido)
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas
>
More information about the Python-ideas
mailing list