[Python-ideas] Add create mode to open()

Guido van Rossum guido at python.org
Wed Aug 17 01:46:49 CEST 2011

On Tue, Aug 16, 2011 at 4:18 PM, Bruce Leban <bruce at leapyear.org> wrote:
> On Tue, Aug 16, 2011 at 3:43 PM, Guido van Rossum <guido at python.org> wrote:
>> 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 :-).
> This isn't look before you leap. It's catching a failure when the file can't
> be created, just as you would if you don't have permission to write a file
> in that directory or the file already exists and is locked so you don't have
> permission to overwrite it. It just adds one more reason the file can't be
> written.

So what's the use case? In general when using a command line
environment overwriting the file is what you *want* to happen. Like
with Unix "foo >bar". I don't even think there *is* a shell syntax for
not overwriting an existing file, though you can use >> to append
instead of overwrite -- this is open(filename, 'a').

> The app should already have code to translate those exceptions into
> human-readable error messages so I don't think that's a good objection.
> (If the implementation of this function in some OS needs LBYL then I think
> that's an unfortunate defect in those OS.)


> I've had enough working with programs that do things like silently eat
> exceptions and I consider silently overwriting a file in the same class.

Always? How would you update an existing file if you can't overwrite files?

--Guido van Rossum (python.org/~guido)

More information about the Python-ideas mailing list