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.<div>
<br></div><div>David<div><br><div class="gmail_quote">On Wed, Aug 17, 2011 at 6:13 AM, Devin Jeanpierre <span dir="ltr"><<a href="mailto:jeanpierreda@gmail.com">jeanpierreda@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Tue, Aug 16, 2011 at 11:49 PM, Benjamin Peterson <<a href="mailto:benjamin@python.org">benjamin@python.org</a>> wrote:<br>
> Devin Jeanpierre <jeanpierreda@...> writes:<br>
>><br>
>> LBYL is impossible here without a race condition, in fact, because the<br>
>> situation can change between looking and leaping. An exception, or<br>
>> else return code, is the only way. These can be checked for after the<br>
>> fact.<br>
><br>
> How often in this used? In every application I've written, writing a file<br>
> usually results from the user giving a path, in which case it's intended to<br>
> replace whatever is already there.<br>
<br>
</div>Unless it isn't. Most GUI apps ask you to confirm whether you want to<br>
open a file even where one exists. Suppose you do a LBYL approach: you<br>
check to see if no file is there, then somebody writes a file there,<br>
then you overwrite it because you used 'w' mode because no file was<br>
there. It's not a disaster, since this is kind of hard to do by<br>
accident, but it is incorrect behavior if you wanted to actually ask<br>
if overwriting was kosher.<br>
<br>
On the other hand, if you ask _after_ trying to open the file, then<br>
one of two things can happen: the user says "abort", or the user says,<br>
"overwrite it". In the former case, we start over. In the latter case,<br>
the only remaining race condition is one that doesn't matter: the file<br>
might disappear before you overwrite it!<br>
<div class="im"><br>
>> I'd also point out that for those that don't want race conditions,<br>
>> Python is discouraging. The correct incantation involves two<br>
>> undocumented constants, plus a unique and rarely used way of opening<br>
>> files that involves unix file descriptors.<br>
><br>
> If you truly want to avoid all filesystem race conditions, you're going to be<br>
> dealing with file descriptors and low-level syscalls galore. Moving one aspect<br>
> to a higher level is not too helpful on the whole.<br>
<br>
</div>Well, eh, not really. As far as I know this particular primitive is<br>
the probably the most important one. It's certainly the only one I've<br>
ever wanted to use<br>
<font color="#888888"><br>
Devin<br>
</font><div><div></div><div class="h5">_______________________________________________<br>
Python-ideas mailing list<br>
<a href="mailto:Python-ideas@python.org">Python-ideas@python.org</a><br>
<a href="http://mail.python.org/mailman/listinfo/python-ideas" target="_blank">http://mail.python.org/mailman/listinfo/python-ideas</a><br>
</div></div></blockquote></div><br></div></div>