Title: open accepts arbitrary mode strings as long as they contain U
Type: behavior Stage: resolved
Components: IO Versions: Python 2.7
Status: closed Resolution: out of date
Dependencies: Superseder:
Assigned To: Nosy List: Arfrever, ezio.melotti, kushal.das, ncoghlan, nneonneo, pitrou, r.david.murray, serhiy.storchaka, wolma
Priority: normal Keywords: patch

Created on 2012-10-04 06:11 by nneonneo, last changed 2020-05-31 15:05 by serhiy.storchaka. This issue is now closed.

File name Uploaded Description Edit
open_mode2.patch kushal.das, 2012-10-04 09:33 _PyFile_SanitizeMode is updated to handle more cases review
Messages (10)
msg171922 - (view) Author: Robert Xiao (nneonneo) * Date: 2012-10-04 06:11
This issue affects Python 2.5 through 2.7, but not Python 3.

open accepts basically anything for the second argument, so long as it either starts with r, w, or a, or contains U somewhere in the string. Therefore, the following are all legal in Python 2.7.3:

>>> open('/tmp/a', 'wail')
<open file '/tmp/a', mode 'wail' at 0x100468ed0>
>>> open('/tmp/a', 'PAIL')
<open file '/tmp/a', mode 'PAIL' at 0x100468270>
>>> open('/tmp/a', 'rabid')
<open file '/tmp/a', mode 'rabid' at 0x100468ed0>
>>> open('/tmp/a', 'alpha[]')
<open file '/tmp/a', mode 'alpha[]' at 0x100468270>
>>> open('/tmp/a', 'raw')
<open file '/tmp/a', mode 'raw' at 0x100468270>

Because the mode string is literally a copy of the passed-in mode, it is not clear at all what the mode of the file actually is. For example, in the last case, I cannot write to the file even though the mode contains 'w', because the mode is actually 'r'. 

I think there are two ways to fix this: either fix the whole mode parsing logic in Objects/fileobject.c to resemble that in Modules/_io/fileio.c from Python 3 (which does proper validation), or just build and store the calculated mode (e.g. "rb") so it's at least possible to determine the file mode.
msg171925 - (view) Author: Kushal Das (kushal.das) * (Python committer) Date: 2012-10-04 07:36
I am working on patch for this.
msg171928 - (view) Author: Kushal Das (kushal.das) * (Python committer) Date: 2012-10-04 09:33
Patch to update mode parsing of open call. All tests seem to be running ok.
File changed: Objects/fileobject.c
msg171945 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2012-10-04 13:37
Unfortunately, this is a backward compatibility concern (currently working-even-if-buggy code could stop working), so I'm -1 on fixing it.  Option [2] would be an enhancement/API change, and is thus also ruled out.  

A third alternative might be to add a warning.
msg172464 - (view) Author: Kushal Das (kushal.das) * (Python committer) Date: 2012-10-09 09:22
So, should I submit a new patch which will just put a warning ?
msg172487 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2012-10-09 15:22
I think we'd probably better find out if there is support for applying it before you go to the trouble of writing it.  It might be appropriate as a -3 warning, since the behavior changes in python3.  I would be +1 for applying it as a -3 warning, and -0 as a not-silenced-by-default warning.
msg240604 - (view) Author: Nick Coghlan (ncoghlan) * (Python committer) Date: 2015-04-13 13:22
+1 for a Py3k warning. Filing a pylint --py3k RFE may also be appropriate.
msg240634 - (view) Author: Wolfgang Maier (wolma) * Date: 2015-04-13 15:58
I'm able to reproduce this with Python 2.7.6 on Linux, but not 2.7.9 on Windows.

Is this a POSIX-only bug or has it been fixed in the meantime ?
msg241356 - (view) Author: Arfrever Frehtes Taifersar Arahesis (Arfrever) * (Python triager) Date: 2015-04-17 19:48
Still reproducible with Python 2.7.10rc0 on GNU/Linux:

>>> open('/tmp/a', 'az')
<open file '/tmp/a', mode 'az' at 0x7f68b117e420>
>>> open('/tmp/a', 'rz')
<open file '/tmp/a', mode 'rz' at 0x7f68b117e4b0>
>>> open('/tmp/a', 'wz')
<open file '/tmp/a', mode 'wz' at 0x7f68b117e420>
>>> open('/tmp/a', 'zU')
<open file '/tmp/a', mode 'zU' at 0x7f68b117e4b0>
msg370477 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2020-05-31 15:05
Python 2.7 is no longer supported.
Date User Action Args
2020-05-31 15:05:44serhiy.storchakasetstatus: open -> closed

nosy: + serhiy.storchaka
messages: + msg370477

resolution: out of date
stage: needs patch -> resolved
2015-04-17 19:48:22Arfreversetmessages: + msg241356
2015-04-13 15:58:40wolmasetnosy: + wolma
messages: + msg240634
2015-04-13 13:22:53ncoghlansetnosy: + ncoghlan
messages: + msg240604
2012-10-09 15:30:05Arfreversetnosy: + Arfrever
2012-10-09 15:22:23r.david.murraysetmessages: + msg172487
2012-10-09 09:22:11kushal.dassetmessages: + msg172464
2012-10-04 13:37:22r.david.murraysetnosy: + r.david.murray
messages: + msg171945
2012-10-04 09:33:05kushal.dassetfiles: + open_mode2.patch
keywords: + patch
messages: + msg171928
2012-10-04 07:36:13kushal.dassetnosy: + kushal.das
messages: + msg171925
2012-10-04 06:41:18ezio.melottisetnosy: + pitrou, ezio.melotti
stage: needs patch

versions: - Python 2.6
2012-10-04 06:12:47nneonneosettype: behavior
2012-10-04 06:11:32nneonneocreate