Message70100
| Author |
pitrou |
| Recipients |
alexandre.vassalotti, gregory.p.smith, loewis, pitrou |
| Date |
2008年07月21日.09:30:16 |
| SpamBayes Score |
0.0011793745 |
| Marked as misclassified |
No |
| Message-id |
<1216632612.48845724ee88b@imp.free.fr> |
| In-reply-to |
<1216475254.64.0.318428334093.issue2523@psf.upfronthosting.co.za> |
| Content |
Selon "Martin v. Löwis" <report@bugs.python.org>:
>
> Martin v. Löwis <martin@v.loewis.de> added the comment:
>
> I don't understand the second loop (where n is given). If n is given,
> there should be only a single read operation, using
>
> max(buffer_size, n-avail)
I mimicked the original logic rather than rethink the algorithm. I'm not totally
sure what motivates the original logic but the purpose seems to be that
non-blocking streams can return at least a few bytes rather than an empty string
when less than N bytes are ready at OS level.
> (i.e. the way it is in patch 2). In particular, if the stream is
> unbuffered, it shouldn't ever end up with buffered data.
Hmm, what do you mean by "if the stream is unbuffered"? Unbuffered streams
should use the raw unbuffered objects (e.g. FileIO) rather than wrap them with
BufferedReader. |
|