On Tue, Apr 5, 2011 at 5:56 PM, Matthew Brett <matthew.br...@gmail.com> wrote: > Hi, > > On Tue, Apr 5, 2011 at 9:46 AM, Christopher Barker > <chris.bar...@noaa.gov> wrote: >> On 4/4/11 10:35 PM, Charles R Harris wrote: >>> 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 disagree that U makes no sense for binary file reading. > > In python 3: > > 'b' means, "return byte objects" > 't' means "return decoded strings" > > 'U' means two things: > > 1) When iterating by line, split lines at any of '\r', '\r\n', '\n' > 2) When returning lines split this way, convert '\r' and '\r\n' to '\n' > > If you support returning lines from a binary file (which python 3 > does), then I think 'U' is a sensible thing to allow - as in this > case.
U looks appropriate in this case, better than the workarounds. However, to me the python 3.2 docs seem to say that U only works for text mode and readline only takes \n as line separator readline(limit=-1) Read and return one line from the stream. If limit is specified, at most limit bytes will be read. The line terminator is always b'\n' for binary files; for text files, the newlines argument to open() can be used to select the line terminator(s) recognized. Josef > > Best, > > Matthew > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
