Logged In: YES 
user_id=38388

Walter, as I've said before: I know that you need buffering
for the UTF-x readline support, but I don't see a
requirement for it in most of the other codecs. E.g. an
ascii codec or latin-1 codec will only ever see standard
line ends (not Unicode ones), so the streams .readline()
method can be used directly - just like we did before the
buffering code was added.

Your argument about applications making implications on the
file position after having used .readline() is true, but
still many applications rely on this behavior which is not
as far fetched as it may seem given that they normally only
expect 8-bit data.

Wouldn't it make things a lot safer if we only use buffering
per default in the UTF-x codecs and revert back to the old
non-buffered behavior for the other codecs which has worked
well in the past ?!

About your patch:

* Please explain what firstline is supposed to do
(preferably in the doc-string).
* Why is firstline always set in .readline() ?
* Please remove the print repr()
* You cannot always be sure that exc has a .start attribute,
so you need to accomocate for this situation as well