On Mon, Apr 4, 2011 at 11:22 PM, Chris Barker <chris.bar...@noaa.gov> wrote:
> On 4/4/11 9:03 PM, josef.p...@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
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
