Yeah, that too should just be documented. The read-until-eof behavior is
quite entrenched (in fact I had a hard time finding example read calls with
a size parameter :-). Specifying a huge buffer size in order to read until
EOF isn't really a common practice, but definitely worth pointing out in
the docs.

On Wed, Aug 27, 2014 at 10:22 AM, Jack O'Connor <report@bugs.python.org>
wrote:

>
> Jack O'Connor added the comment:
>
> Agreed that changing read() would probably break tons of people. I don't
> think a naming inconsistency meets the "serious flaws are uncovered" bar
> for breaking a provisional package. If we actually prefer the asyncio way
> of doing things, all the better.
>
> That said, another thing I'm noticing is that in asyncio, read is
> basically two different functions. This is clear in the code,
> http://hg.python.org/cpython/file/fb3aee1cff59/Lib/asyncio/streams.py#l433,
> where the n<0 case goes off on its own branch and never comes back.
> (Incidentally there's another n<0 check at line 453 there that I think
> always returns false.) We have a read function that makes very different
> guarantees depending on the value of n. Contrast this with the read
> function from regular io, where read(n) and read() are effectively the same
> if n is large enough. Maybe just another point that's worth clarifying in
> the docs.
>
> Thanks for the quick replies!
>
> ----------
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue22279>
> _______________________________________
>