On Mon, Apr 4, 2011 at 11:22 PM, Chris Barker <Chris.Barker@noaa.gov> wrote:
On 4/4/11 9:03 PM, josef.pktd@gmail.com wrote:
On Mon, Apr 4, 2011 at 11:42 PM, Charles R Harris
File "/sw/lib/python2.4/site-packages/numpy/lib/_datasource.py", line 477, in open return _file_openers[ext](found, mode=mode) IOError: invalid mode: Ub
Guess that wasn't tested before ;) I thought that was strange when I saw it. The source of the problem is line 2035 in npyio.py. Additionally, Since genloadtxt needs to have byte strings the 'rb" mode should probably be used. That works on linux, both for python 2 and python 3, but doing that might uncover genfromtxt problems on other platforms.
"rb" is fine on Windows with python 3.2, (that's what I tested initially for this bug)
IIUC, "Ub" is undefined -- "U" means universal newlines, which makes no sense when used with "b" for binary. I looked at the code a ways back, and I can't remember the resolution order, but there isn't any checking for incompatible flags.
I'd expect that genfromtxt, being txt, and line oriented, should use 'rU'. but if it wants the raw line endings (why would it?) then rb should be fine.
"U" has been kept around for backwards compatibility, the python documentation recommends that it not be used for new code. Whatever 'new' means in this case ;) If it is unneeded for python 2.4 I say drop it. Note that if you only test with unix (\n) and dos (\r\n) line endings,
it may work with 'b', if it's splitting on '\n', but not if you try it with Mac endings (\r). Of course with OS-X mac endings are getting pretty uncommon.
I suppose we could try the different line endings on a single platform and see what happens. It would be nice to know just how portable text really is. Chuck