This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author nikratio
Recipients benjamin.peterson, hynek, nikratio, pitrou, r.david.murray, serhiy.storchaka, stutzbach
Date 2013-07-24.21:45:32
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <51F04B4F.1030105@rath.org>
In-reply-to <1374701309.2619.1.camel@fsol>
Content
On 07/24/2013 02:28 PM, Antoine Pitrou wrote:
> 
> Antoine Pitrou added the comment:
> 
> Le mercredi 24 juillet 2013 à 18:24 +0000, Nikolaus Rath a écrit :
>> There should be no problem reading 20 bytes with a single call to
>> BytesIO.read(), yet the buffered reader returns only 10 bytes.
> 
> Er. Your bug report seems to imply that read1(n) can return *more* than
> n bytes, which would be a bug.
> That it may return less than n bytes is correct, though.

I admit the bug title may not have been chosen carefully enough.

The documentation is correct that read1(n) never returns more than n bytes.

My complaint is that the actual bound is stricter than this, band
read1(n) will never return more than min(n, bufsize) bytes.

To me, this seems unnecessary and counterintuitive. Why am I restricted
by the buffer size if the underlying raw device could provide the
requested amount with one call?

Looking at the source, this restriction seems caused by read1() calling
peek(). I think it would be straightforward to just delegate a read1(n)
call to raw stream's read(n) method.

This would improve performance, and also make the documentation more
accurate.

Did I miss something?

Best,
Nikolaus
History
Date User Action Args
2013-07-24 21:45:32nikratiosetrecipients: + nikratio, pitrou, benjamin.peterson, stutzbach, r.david.murray, hynek, serhiy.storchaka
2013-07-24 21:45:32nikratiolinkissue18524 messages
2013-07-24 21:45:32nikratiocreate