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.

I am working on patch for this.

Patch to update mode parsing of open call. All tests seem to be running ok.
File changed: Objects/fileobject.c

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.

So, should I submit a new patch which will just put a warning ?

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.

+1 for a Py3k warning. Filing a pylint --py3k RFE may also be appropriate.

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 ?

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>

Python 2.7 is no longer supported.