Bob Ippolito wrote:
>> [...]
>> 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.
It isn't: the default is still keepends=True. (In fact changing it
breaks the PEP 263 functionality).
> While this reasoning makes sense for readline(), it most definitely does
> not for readlines() or __iter__(). unicode objects have a splitlines()
That's exactly where I got the idea from. And it frees the user from
having to deal with the various possible line endings (\r, \n, \r\n,
\u2028). But note that the patch doesn't implement this yet, it only
breaks lines at \n.
> 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.
Bye,
Walter Dörwald
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4