RetroSearch Browse

Wed Jul 28 04:20:24 CEST 2004 · http://mail.python.org/pipermail/python-dev/2004-July/046469.html

On Jul 27, 2004, at 9:26 PM, Josiah Carlson wrote:

>
>> - readline() and readlines() have an additional option
>>    for dropping the u"\n".
>
> I'll point out (since no one else has so far) that the reasons for
> keeping the linefeed at the end of lines returned by readline() and
> readlines() are documented here:
> http://docs.python.org/lib/bltin-file-objects.html#foot3271
>
> Specifically it allows one to use the following and have it "do the
> right thing".
>
> while 1:
>     line = obj.readline()
>     if not line:
>         break
>     process(line)
>
> Having the option of readline() and readlines() being ambiguous 
> anywhere
> sounds like a misfeature.  Furthermore, since all other readline and
> readlines calls that do not inherit from StreamReader use the
> unambiguous "always include the line ending", changing StreamReader to
> be different is obviously the wrong thing to do.

While this reasoning makes sense for readline(), it most definitely 
does not for readlines() or __iter__().  unicode objects have a 
splitlines() function with this feature, which is probably what he's 
using in his implementation (I used it in mine), so it's pretty natural 
to expose that option to the external interface.

-bob
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3589 bytes
Desc: not available
Url : http://mail.python.org/pipermail/python-dev/attachments/20040727/70120db2/smime-0001.bin

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from http://mail.python.org/pipermail/python-dev/2004-July/046469.html below:

[Python-Dev] Decoding incomplete unicode