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 pitrou
Recipients benjamin.peterson, daniel.urban, jcon, pitrou, stutzbach
Date 2011-05-05.19:06:14
SpamBayes Score 3.1042302e-05
Marked as misclassified No
Message-id <1304622371.3564.11.camel@localhost.localdomain>
In-reply-to <1304555737.32.0.0606655470844.issue9971@psf.upfronthosting.co.za>
Content
> As I think about this more... I'm not sure how much performance there
> is to gain here in practice.  It seems like any time I'd want to use
> readinto(), it's because I want to do my own buffering, in which case
> why would I use a BufferedReader?

The difference between buffered I/O and raw I/O isn't only the presence
of a buffer. For example read(N) on a buffered object will loop until N
bytes are satisfied (or EOF is reached), while read(N) on a raw I/O
object will give you whatever the system call returns.

I would add that third-party buffering would be better helped by the
prefetch() method I proposed on python-ideas:
http://mail.python.org/pipermail/python-ideas/2010-September/008179.html

readinto() is really about minimizing copies and allocations when you
already have storage allocated for the result.
(note that TextIOWrapper could have used readinto(), but instead opted
for the slightly useless read1())
History
Date User Action Args
2011-05-05 19:06:15pitrousetrecipients: + pitrou, benjamin.peterson, stutzbach, daniel.urban, jcon
2011-05-05 19:06:14pitroulinkissue9971 messages
2011-05-05 19:06:14pitroucreate