>> Finally, not specific to this change, but I wonder if rather than
    >> having distinct io.StringIO and io.BytesIO classes it would be better
    >> to have a single io.MemoryIO class which takes mode arguments just
    >> like io.FileIO?  The correspondence between file-based and memory-
    >> based i/o would be more one-to-one.  Such a class could be added
    >> without breaking existing code by using the StringIO and BytesIO
    >> classes as the back-end for a MemoryIO class.

    Benjamin> What advantage would that have?

File I/O and memory I/O would have more uniform in their APIs and thus be
easier to document, describe and use.  Currently, one class is used to do
file I/O.  The type of I/O done is controlled by the mode and buffering
flags.  Two distinct classes are used to do memory I/O.

If someone wanted to select between file and memory I/O at runtime it
wouldn't be possible to just swap the class using the current code.

Skip