msg79043 - (view) |
Author: Ulrich Eckhardt (eckhardt) |
Date: 2009-01-04 11:17 |
Specifying the '+' more than once while opening a file results in the error "Must have exactly one of read/write/append mode". The attached patch extends that with ".. and at most one optional plus". Further, the patch checks these after the loop that parses the mode string, avoiding some unnecessary gotos and saving a few lines of code overall. |
|
|
msg88503 - (view) |
Author: John Szakmeister (jszakmeister) * |
Date: 2009-05-29 10:06 |
On trunk, it seems that it's perfectly happy if you specify more than one '+': Python 2.7a0 (trunk, May 29 2009, 05:57:26) [GCC 4.0.1 (Apple Inc. build 5470) (Aspen 5470.3)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> open('foo.txt', 'w++') <open file 'foo.txt', mode 'w++' at 0x39b2a0> Is this still really an issue then? The current trunk also allows multiple mode letters too, so it seems like a decision has been made. |
|
|
msg88734 - (view) |
Author: Ulrich Eckhardt (eckhardt) |
Date: 2009-06-02 09:46 |
Good catch, it just took me a while to actually figure out myself where the bug is. Try the following instead: import io io.FileIO('foo.text', 'w++') This will yield "ValueError: Must have exactly one of read/write/append mode" with 2.6 on win32. I haven't tested on the latest 2.x or 3.x branches, but looking at the 2.7 branch, I see the faulty code is still there. BTW: Using io.open('foo.text', 'w++') yields "ValueError: invalid mode: 'w++'", I would have expected the same error as for io.FileIO() above. Using open('foo.text', 'w++') works. Using open('foo.text', 'ww++') yields "IOError: [Errno 22] invalid mode ('ww++') or filename: 'foo.text')". In other words, Python 2.6 is behaving a bit inconsistent here. The patch only fixes one of those issues, the others and the necessary unit tests remain. |
|
|
msg89072 - (view) |
Author: John Szakmeister (jszakmeister) * |
Date: 2009-06-08 10:05 |
The offending lines in io.py are: modes = set(mode) if modes - set("arwb+tU") or len(mode) > len(modes): raise ValueError("invalid mode: %r" % mode) In particular, the "or len(mode) > len(modes)" is picking off the fact that there is repeated mode characters. Leaving that off allows io.open() to behave exactly like the built-in open() call. OTOH, someone obviously wanted to make sure that repeat mode characters were not allowed. So I guess someone needs to rule on whether we want io.open() and io.FileIO() to behave like the built-in, or to keep things more strict. |
|
|
msg119295 - (view) |
Author: Georg Brandl (georg.brandl) *  |
Date: 2010-10-21 13:45 |
Amended error message in r85773. |
|
|