M.-A. Lemburg <mal <at> egenix.com> writes:
What I don't understand is why the io layer tries to reinvent the wheel here instead of just using the codec's .readline() method - which *does* use .splitlines() and has full support for all Unicode line break characters (including the CRLF combination).
As for the original Python implementation, the goal was probably to start from a clean sheet. Besides, the new API has seek() and tell() as well. But I'm not really qualified to say more -- I didn't participate in its design.
As for the C implementation, it had to be written from scratch anyway -- codecs.open() is pure Python and too slow. Deferring to str.splitlines() would still have been possible but a bit wasteful since in C you can use buffers directly.
(and, besides, when writing the C implementation we were concerned with exact compatibility with the Python version -- including line break semantics)