Yann Leboulanger wrote:
> Tim Golden a écrit :
>>
>> I'm happy to contribute a doc patch if I can imagine what
>> exactly to write.
>>
>
> "Don't use it under windows, always consider it's True"?
Well, that's not the case for files: if you set your
file's readonly attribute to True, then os.access (W_OK)
will return False and you won't be able to write to the
file:
<code>
import os
open ("temp.tmp", "w").close ()
os.access ("temp.tmp", os.W_OK)
os.system ("attrib +r temp.tmp")
os.access ("temp.tmp", os.W_OK)
open ("temp.tmp", "w").close ()
os.system ("attrib -r temp.tmp")
os.access ("temp.tmp", os.W_OK)
</code>
> Maybe it would be a good idea to remove support for windows for this
> function, or make it always return True?
The only issue (at least, the only one we're discussing here) is:
If os.W_OK on a directory returns True, that won't stop you writing
into that directory.
> Current behaviour is worth that nothing, access() return False but
> open() doesn't fail ...
To be precise: open () on a file within that directory doesn't fail.
Personally, I sympathise with you here. Python comes from a Unix
background and, unsurprisingly, it offers all the major Unix
system calls. Since Windows historically offered a Posix layer
which mapped them to *something*[1], the developers simply called
those under the covers. And the basic policy was: whatever Windows
passes back to Python, Python passes on to you.
Later (mid-2006, I think) some or all of these Posix-layer functions
were replaced by native Win32 APIs. At that point, it arguably became
Python's responsibility to define semantics. But it's a fuzzy sort of
area. I think a doc patch which said something like: "Calls
FileGetAttribute[A|W] and compares against FILE_READONLY_ATTRIBUTE"
might meet the case, although a bit of a cop-out.
TJG
[1] http://msdn2.microsoft.com/en-us/library/1w06ktdy(VS.80).aspx
--
http://mail.python.org/mailman/listinfo/python-list
