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

[David Townshend]

It seems that the only problem raised which hasn't been already responded to
is that it won't necessarily work on all platforms.  Could anyone elaborate
on which platforms it won't work on?  From what I've read it will work on
all unix and windows systems which I think covers the majority.  I can't see
that it would be a problem if it doesn't work on a few specialised systems
as long as the documentation is clear on this (any it might turn out that it
can be handled, just through os-specific code).  It at least allows the
feature to be available for the 90% of use cases when it will work.

David

On Wed, Aug 17, 2011 at 6:13 AM, Devin Jeanpierre <jeanpierreda at gmail.com>wrote:

> On Tue, Aug 16, 2011 at 11:49 PM, Benjamin Peterson <benjamin at python.org>
> wrote:
> > Devin Jeanpierre <jeanpierreda at ...> writes:
> >>
> >> 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.
> >
> > How often in this used? In every application I've written, writing a file
> > usually results from the user giving a path, in which case it's intended
> to
> > replace whatever is already there.
>
> Unless it isn't. Most GUI apps ask you to confirm whether you want to
> open a file even where one exists. Suppose you do a LBYL approach: you
> check to see if no file is there, then somebody writes a file there,
> then you overwrite it because you used 'w' mode because no file was
> there. It's not a disaster, since this is kind of hard to do by
> accident, but it is incorrect behavior if you wanted to actually ask
> if overwriting was kosher.
>
> On the other hand, if you ask _after_ trying to open the file, then
> one of two things can happen: the user says "abort", or the user says,
> "overwrite it". In the former case, we start over. In the latter case,
> the only remaining race condition is one that doesn't matter: the file
> might disappear before you overwrite it!
>
> >> 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.
> >
> > If you truly want to avoid all filesystem race conditions, you're going
> to be
> > dealing with file descriptors and low-level syscalls galore. Moving one
> aspect
> > to a higher level is not too helpful on the whole.
>
> Well, eh, not really. As far as I know this particular primitive is
> the probably the most important one. It's certainly the only one I've
> ever wanted to use
>
> Devin
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20110817/9d2e40d8/attachment.html>