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 amaury.forgeotdarc, barry, benjamin.peterson, donmez, giampaolo.rodola, gpolo, loewis, pitrou, teoliphant
Date 2008-07-31.00:16:33
SpamBayes Score 3.993594e-06
Marked as misclassified No
Message-id <1217463391.7662.12.camel@fsol>
In-reply-to <1217462405.17.0.567611973283.issue3139@psf.upfronthosting.co.za>
Content
Le jeudi 31 juillet 2008 à 00:00 +0000, Amaury Forgeot d'Arc a écrit :
> Amaury Forgeot d'Arc <amauryfa@gmail.com> added the comment:
> 
> > If it was rewritten to use a fixed-size bytearray
> does such an object exist today?

Manually, yes :)
Just preallocate your bytearray, e.g.:
    b = bytearray(b" " * 4096)

and then be careful to only do operations (e.g. slice assignments) which
keep the size intact.
In a BufferedWriter implementation, you would have to keep track of the
currently used chunk in the bytearray (offset and size).

Anyway, I'd question the efficiency of the bytearray approach; when
removing the quadratic behaviour in BufferedReader I discovered that
using a bytearray was slower than keeping a list of bytes instances and
joining them when needed (not to mention that the latter is inherently
thread-safe :-)). The reason is that the underlying raw stream expects
and returns bytes, and the public buffered API also does, so using a
bytearray internally means lots of additional memory copies.

(a related problem is that readinto() does not let you specify an offset
inside the given buffer object, it always starts writing at the
beginning of the buffer. Perhaps memoryview() will support creating
subbuffers, I don't know...)
History
Date User Action Args
2008-07-31 00:16:36pitrousetrecipients: + pitrou, loewis, barry, teoliphant, amaury.forgeotdarc, giampaolo.rodola, donmez, benjamin.peterson, gpolo
2008-07-31 00:16:35pitroulinkissue3139 messages
2008-07-31 00:16:33pitroucreate