[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

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 at scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>



More information about the NumPy-Discussion mailing list