Message310035
| Author |
martin.panter |
| Recipients |
kata198, martin.panter, pitrou |
| Date |
2018年01月16日.05:02:59 |
| SpamBayes Score |
-1.0 |
| Marked as misclassified |
Yes |
| Message-id |
<1516078979.78.0.467229070634.issue32475@psf.upfronthosting.co.za> |
| In-reply-to |
| Content |
If I remember the implementation of "peek" right, it may do what you want. But the documentation doesn’t guarantee much about its behaviour; see Issue 5811.
Anyway, I agree that a "getbuffn" method (or property) would be nice. (Perhaps with a better name!) But please don’t add it to the abstract APIs like BufferedIOBase. It could break compatibility with third-party implementations, or make the API complicated with little benefit. Just extend the concrete APIs like BufferedReader.
Two other use cases where the "peek" implementation won’t help, but "getbuffn" would:
1. Issue 32561: Decide whether a non-blocking "read" call is possible, or if a background read (e.g. of a regular "disk" file) should be started instead.
2. Get the pending unread data before it is lost by calling "BufferedReader.detach". |
|
History
|
|---|
| Date |
User |
Action |
Args |
| 2018年01月16日 05:02:59 | martin.panter | set | recipients:
+ martin.panter, pitrou, kata198 |
| 2018年01月16日 05:02:59 | martin.panter | set | messageid: <1516078979.78.0.467229070634.issue32475@psf.upfronthosting.co.za> |
| 2018年01月16日 05:02:59 | martin.panter | link | issue32475 messages |
| 2018年01月16日 05:02:59 | martin.panter | create |
|