This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

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.
History
Date User Action Args
2011-08-18 15:14:16neologixsetrecipients: + neologix, pitrou, vstinner, benjamin.peterson, docs@python, Julian, David.Townshend
2011-08-18 15:14:16neologixsetmessageid: <1313680456.87.0.302575181883.issue12760@psf.upfronthosting.co.za>
2011-08-18 15:14:16neologixlinkissue12760 messages
2011-08-18 15:14:15neologixcreate