It has a typo error in cStringIO.StringIO's class name "StringO":

>>> import cStringIO
>>> a=cStringIO.StringIO()
>>> a
<cStringIO.StringO object at 0xb7eef240>
>>> a.__class__.__name__
'StringO'

So we can't unpickle the object correctly with Python 2.5.4:

>>> import pickle
>>> pickle.loads(pickle.dumps(a))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python2.5/pickle.py", line 1366, in dumps
    Pickler(file, protocol).dump(obj)
  File "/usr/local/lib/python2.5/pickle.py", line 224, in dump
    self.save(obj)
  File "/usr/local/lib/python2.5/pickle.py", line 306, in save
    rv = reduce(self.proto)
  File "/usr/local/lib/python2.5/copy_reg.py", line 69, in _reduce_ex
    raise TypeError, "can't pickle %s objects" % base.__name__
TypeError: can't pickle StringO objects

When using multiprocess library, it also use the pickling and unpickling
of cStringIO.StringIO object

This bug also exists in Python 2.6.1

The documentation says:

"Another difference from the StringIO module is that calling StringIO()
with a string parameter creates a read-only object. Unlike an object
created without a string parameter, it does not have write methods. These
objects are not generally visible. They turn up in tracebacks as StringI
and StringO."

And there seem to have been some activity about this around r33834.

This is not a typo. cStringIO.StringIO is a factory function that
returns either a cStringO object (for writing) or cStringI (for
reading). If this behavior causes a problem to you, then consider using
StringIO.StringIO.

Alternatively, you could upgrade to Python 2.7 or 3.0 and use
io.StringIO() which doesn't have this limitation.