On 16 Jul 2014 20:00, <dw+python-dev@hmmz.org> 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 is not that hard to write an own wrapper that
> > won't do copies (or to port [c]StringIO to 3.x), but I wonder if there is an
> > existing solution or plans to fix it in Python itself - this BytesIO use case
> > looks quite important.
>
> Regarding a fix, the problem seems mostly that the StringI/StringO
> specializations were removed, and the new implementation is basically
> just a StringO.

Right, I don't think there's a major philosophy change here, just a missing optimisation that could be restored in 3.5.

Cheers,
Nick.


">

(original) (raw)

That was an impressively fast draft patch!



2014-07-17 7:28 GMT+06:00 Nick Coghlan <ncoghlan@gmail.com>:


On 16 Jul 2014 20:00, <dw+python-dev@hmmz.org> 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 is not that hard to write an own wrapper that
\> > won't do copies (or to port \[c\]StringIO to 3.x), but I wonder if there is an
\> > existing solution or plans to fix it in Python itself - this BytesIO use case
\> > looks quite important.
\>
\> Regarding a fix, the problem seems mostly that the StringI/StringO
\> specializations were removed, and the new implementation is basically
\> just a StringO.

Right, I don't think there's a major philosophy change here, just a missing optimisation that could be restored in 3.5.

Cheers,
Nick.