On 8/6/07, Georg Brandl <[EMAIL PROTECTED]> wrote:
> Okay, I propose the following patch:
> [...]
I think your patch is complicated for nothing. It would be much more
straightforward to use PyString_AsStringAndSize to encode the Unicode
string with the default encoding. I think it would be necessa
Oops, never mind. This was in the context of 2.5 and 2.6, but my reply
was in the context of 3.0. Still, in the light of cStringIO
disappearing, it would be good to keep cStringIO is stable as possible
(probably restoring 2.5.0 behavior) so as to avoid breaking 3rd party
code more than once.
On 8/
On 8/6/07, Georg Brandl <[EMAIL PROTECTED]> wrote:
> Guido van Rossum schrieb:
> > Methinks that this was a fundamental limitation of cStringIO, not a
> > bug. Certainly not something to be "fixed" in a bugfix release.
>
> I'm sorry.
No problem. Somebody else should have flagged this, so it's our
Guido van Rossum schrieb:
> Methinks that this was a fundamental limitation of cStringIO, not a
> bug. Certainly not something to be "fixed" in a bugfix release.
I'm sorry.
Martin v. Löwis schrieb:
>> See bugs #1548891 and #1730114.
>>
>> In the former, it was reported that cStringIO works diff
On 8/5/07, Georg Brandl <[EMAIL PROTECTED]> wrote:
> See bugs #1548891 and #1730114.
>
> In the former, it was reported that cStringIO works differently from StringIO
> when handling unicode strings; it used GetReadBuffer which returned the raw
> internal UCS-2 or UCS-4 encoded string.
>
> I change
> See bugs #1548891 and #1730114.
>
> In the former, it was reported that cStringIO works differently from StringIO
> when handling unicode strings; it used GetReadBuffer which returned the raw
> internal UCS-2 or UCS-4 encoded string.
>
> I changed it to use GetCharBuffer, which converts to a st
Methinks that this was a fundamental limitation of cStringIO, not a
bug. Certainly not something to be "fixed" in a bugfix release.
On 8/5/07, Georg Brandl <[EMAIL PROTECTED]> wrote:
> See bugs #1548891 and #1730114.
>
> In the former, it was reported that cStringIO works differently from StringI
See bugs #1548891 and #1730114.
In the former, it was reported that cStringIO works differently from StringIO
when handling unicode strings; it used GetReadBuffer which returned the raw
internal UCS-2 or UCS-4 encoded string.
I changed it to use GetCharBuffer, which converts to a string using the