His addition of readsize to readline() doesn't do the same as readline(n) does for regular files -- there it reads at most n characters, period.

The only part of this patch I like is the readsize argument to readlines(), which *does* (roughly) do the same as for regular files.

You can rework this to implement readline(maxread=-1) and readlines(sizehint=0) and then I'd be okay.

Almost right.  The docs for file objects specifically imply that a negative arg to readline() or a zero arg to readlines() is the same as no args; your defaults are sys.maxint so an explicit -1 or 0 won't do the right thing. (This is important for wrapper classes that want to implement the same conventions.)

This is my only objection; you can check it in if you fix this.

Argh!  You seem to have reversed the -1 and 0.  (I apologize for the confusion.)

The default is readline(-1), readlines(0).

Patch from Wolfgang Grafen <wolfgang.grafen@marconicomms.com> that I didn't want to lose.  From his e-mail:

- readline accepts readsize argument
- readlines accepts readsize argument
- readlines accepts optional 'strip_cr' arguments, which is often convenient for me and also speeds up the routine :)

[amk] The strip_cr thing is a non-starter, but I'll look at adding the other changes.

Completely revised this patch and changed status from 'rejected' to 'open'.  This version gives now the optional
integer arguments to .readline() and .readlines() the same
semantics as they have for regular file objects.  

(The patch also rearranges a few import statements, and completes a sentence fragment in a comment.)

Two-line change to give -1 and 0 the correct semantics
for readline and readlines.  

Revised patch to swap the default values.

I also want to beef up the test suite to exercise the new functionality --
will work on that tonight.