Message10742

We are going to have to defer this to 2.7.2. The basic problem is as follows:

CPython implements the Python types cStringIO.StringI and cStringIO.StringO, with cStringIO being a factory function that selects the appropriate type. Jython, in contrast, currently has one common class, StringIO and allows for mixing input and output by using an underlying StringBuilder. In the most common case, output ("StringO"), there is no distinction in semantics.

But for the "StringI" case, and this can be seen with bytearray, we need to implement StringI's support for taking a buffer protocol argument and allowing mutation on the underlying data. So here's what can happen:

$ python
Python 2.7.10 (v2.7.10:15c95b7d81dc, May 23 2015, 09:33:12)
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from cStringIO import StringIO
>>> x = bytearray("foobar")
>>> s = StringIO(x)
>>> s.getvalue()
'foobar'
>>> x[0] = "F"
>>> s.getvalue()
'Foobar'
>>> s
<cStringIO.StringI object at 0x1006ba4f8>

In addition, StringI only supports reads, which makes sense since it's tied to the underlying object's backing data via the buffer protocol:

>>> s.write("baz")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'cStringIO.StringI' object has no attribute 'write'

In working out this issue, I did come up with a preliminary patch to further extend these semantics for partial bytearray approach, which works by doing a copy of the bytearray data. But we need to implement buffer protocol semantics instead.

In 2.7.2, we can do this properly: complete rewrite of the cStringIO module (which is minimal work, it is about 450 lines) and implement the Python types StringI and StringO with correct Python semantics, using Jython's standard expose approach. However, it's too late in the release cycle of 2.7.1 to do this work now.