@pelson: Done.

@mdboom: Yeah the code was written in 2005 and wasn't really changed since. I assume the corner case is what the Python manual for os.access hints at: "Note: I/O operations may fail even when `access()` indicates that they would succeed, particularly for operations on network filesystems which may have permissions semantics beyond the usual POSIX permission-bit model."

I don't know what this means in practice. Is there a concrete example of access() returning True for a directory but you can't create files in it? Creating and deleting a temporary file seems like a messy thing to do if there is a function that tells you directly whether a directory is writable. But I am happy to put it back. The App Engine corner case is a failure in the other direction: TemporaryFile succeeds even though the file system is not writable (since TemporaryFile just creates a StringIO, ignoring the dir argument). So it should be fine to have both checks: os.access() to check if it is theoretically writable (which works for App Engine), followed up by TemporaryFile to test if it is writable in practice. Should I go ahead and do this?

> At the very least, this should use `realpath` of `p` to resolve any symbolic links.

I don't think so. From `man 2 access`:

> If `pathname` is a symbolic link, it is dereferenced.

I tested this on Linux and it seemed to work (created a non-writable directory and a writable symlink to the directory; `os.access` with `W_OK` on the symlink returns False).