CLN: StringIO from io instead of from StringIO

[kawochen]

It looks like io is available from 2.6 onward. Can I move the importing out of compat (and replaces any cStringIO with StringIO)? StringIO.StringIO doesn't always do the same thing as io.StringIO.

[jreback]

cStringIO is aliased to StringIO so this shouldn't be any differnt

[kawochen]

Yes, in Python 3 they are aliases. In Python 2 the cStringIO and StringIO modules are used, but I believe io is available for all versions of Python supported. In particular #10369 is reproducible only in Python 2 because of the difference between StringIO.StringIO and io.StringIO

[jreback]

they are also aliased in py2 on purpose

where is io.stringio different? do u have a reference

[kawochen]

The only thing I'm aware of other than performance is the input allowed. StringIO.StringIO strs input, so it accepts [], None, {} and anything it can convert, whereas io.StringIO accepts unicode and None. And I need to correct myself because the issue I referenced calls StringIO.StringIO on Python 2 and io.BytesIO (not io.StringIO) on Python 3.

StringIO.StringIO(None).getvalue() returns 'None'
io.StringIO(None).getvalue() returns u''
StringIO.StringIO({}).getvalue() returns '{}'
io.StringIO({}).getvalue() raises

[shoyer]

Indeed, seems like a good idea to use io.StringIO or io.BytesIO.

@jreback The io module was basically a backport from Python 3 to Python 2:
https://docs.python.org/2/library/io.html

[jreback]

@kawochen so nothing against this, if it passes the current suite prob ok. Though these edge cases may not be tested, so if you can gin up something where StringIO.StringIO(...) fails and io.StringIO(...) passes would be good as well

[jreback]

@kawochen ahh good point.

[jorisvandenbossche]

The compat version has been removed (#25954), so this can be closed.