Guido van Rossum added the comment: 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 <rep...@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 <rep...@bugs.python.org> > <http://bugs.python.org/issue22279> > _______________________________________ > ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue22279> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
