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 nadeem.vawda
Recipients Arfrever, ethan.furman, jcea, nadeem.vawda, oylenshpeegul, python-dev, terry.reedy, vajrasky, vstinner
Date 2013-10-18.22:41:36
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1382136096.66.0.997259752237.issue19201@psf.upfronthosting.co.za>
In-reply-to
Content
[terry.reedy]
| Arfrever's point about the order of characters makes me wonder why mode
| strings (as opposed to characters in the strings) are being checked.
| The following tests that exactly one of w, a, x appear in mode.
|  if len({'w', 'a', 'x'} & set(mode)) == 1:
| If mode is eventually passed to open(), the latter would do what ever
| it does with junk chars in mode (such as 'q').

There are two separate questions here - how rigid we are about modes
containing only valid characters, and how we handle invalid characters.

I don't think there's any point in passing through unrecognized chars
to builtins.open(), since it results in a ValueError either way.

On the first point, the code only accepts modes like 'r' and 'rb' (but
not 'br') for the sake of simplicity. There doesn't seem to be much
practical value in accepting arbitrarily-ordered modes, but if someone
has a compelling use-case (or a patch that's no more complex than the
status quo), please bring it up in a separate issue.
History
Date User Action Args
2013-10-18 22:41:36nadeem.vawdasetrecipients: + nadeem.vawda, terry.reedy, jcea, vstinner, Arfrever, ethan.furman, python-dev, vajrasky, oylenshpeegul
2013-10-18 22:41:36nadeem.vawdasetmessageid: <1382136096.66.0.997259752237.issue19201@psf.upfronthosting.co.za>
2013-10-18 22:41:36nadeem.vawdalinkissue19201 messages
2013-10-18 22:41:36nadeem.vawdacreate