That was an impressively fast draft patch!
2014-07-17 7:28 GMT+06:00 Nick Coghlan :
>
> On 16 Jul 2014 20:00, wrote:
> > On Thu, Jul 17, 2014 at 03:44:23AM +0600, Mikhail Korobov wrote:
> > > I believe this problem affects tornado (
> https://github.com/tornadoweb/tornado/
> > > Do you know if
Hi,
Le 16/07/2014 19:07, dw+python-...@hmmz.org a écrit :
Attached is a (rough) patch implementing this, feel free to try it with
hg tip.
Thanks for your work. Please post any patch to http://bugs.python.org
Regards
Antoine.
___
Python-Dev mai
On 16 Jul 2014 20:00, wrote:
> On Thu, Jul 17, 2014 at 03:44:23AM +0600, Mikhail Korobov wrote:
> > I believe this problem affects tornado (
https://github.com/tornadoweb/tornado/
> > Do you know if there a workaround? Maybe there is some stdlib part that
I'm
> > missing, or a module on PyPI? It i
It's worth note that a natural extension of this is to do something very
similar on the write side: instead of generating a temporary private
heap allocation, generate (and freely resize) a private PyBytes object
until it is exposed to the user, at which point, _getvalue() returns it,
and converts
On Thu, Jul 17, 2014 at 03:44:23AM +0600, Mikhail Korobov wrote:
> So making code 3.x compatible by ditching cStringIO can cause a serious
> performance/memory regressions. One can change the code to build the data
> using BytesIO (without creating bytes objects in the first place), but that is
>
Hi,
cStringIO was removed from Python 3. It seems the suggested replacement is
io.BytesIO. But there is a problem: cStringIO.StringIO(b'data') didn't copy
the data while io.BytesIO(b'data') makes a copy (even if the data is not
modified later).
This means io.BytesIO is not suited well to cases wh
