Message142333
| Author |
neologix |
| Recipients |
David.Townshend, Julian, benjamin.peterson, docs@python, neologix, pitrou, vstinner |
| Date |
2011年08月18日.15:14:15 |
| SpamBayes Score |
0.00013533577 |
| Marked as misclassified |
No |
| Message-id |
<1313680456.87.0.302575181883.issue12760@psf.upfronthosting.co.za> |
| In-reply-to |
| Content |
> Yeah, but I think "exclusively" is quite misleading since it does not
> perform any locking of any kind.
It might be misleading, but I find it clear enough, and this name has been endorsed by POSIX.
Furthermore, there's an added bonus: actually, with the old I/O layer, one can already pass an 'x' flag to open, since it just calls fopen:
"""
cf@neobox:~$ strace -e open python -c "open('/tmp/foo', 'wx')"
[...]
open("/tmp/foo", O_WRONLY|O_CREAT|O_EXCL|O_TRUNC|O_LARGEFILE, 0666) = 3
cf@neobox:~$ strace -e open python -c "open('/tmp/foo', 'wx')"
[...]
open("/usr/lib/pymodules/python2.6/<string>", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
IOError: [Errno 17] File exists: '/tmp/foo'
"""
I don't know if it's documented behavior, but the OP in issue 12105 was using it with python 2.
Changing it to 'x' would make such code backward-compatible.
Finally, when I read open('/tmp/foo', 'wx'), it's immediately clear to me what's going on, while I'd have to look at open()'s documentation to find out what the 'c' flag does. |
|