[Numpy-discussion] ANN: Numpy 1.6.0 beta 2

josef.pktd at gmail.com josef.pktd at gmail.com
Tue Apr 5 18:36:30 EDT 2011

On Tue, Apr 5, 2011 at 5:56 PM, Matthew Brett <matthew.brett at gmail.com> wrote:
> Hi,
> On Tue, Apr 5, 2011 at 9:46 AM, Christopher Barker
> <Chris.Barker at 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

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.


> Best,
> Matthew
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion

More information about the NumPy-Discussion mailing list