[Python-3000] StringIO vs cStringIO, pickle vs cPickle

[Guido van Rossum]

On 4/4/06, Aahz <aahz at pythoncraft.com> wrote:
> On Tue, Apr 04, 2006, Just van Rossum wrote:
> > Has there been any discussion yet about StringIO vs cStringIO and pickle
> > vs cPickle?
>
> Now there is!
>
> > While I appreciate that there are maintained pure Python versions of
> > those modules, as a user it irritates me that I have the choice. The
> > argument so far for not replacing StringIO with cStringIO was that
> > they're subtly incompatible (mostly StringIO's "feature" to support
> > unicode, right?), so Python 3000 seems like a good time to reconsider
> > that option. I don't see any reason to not always want to prefer the
> > faster version.
>
> Suggestion: make string_io (we're renaming the module, right?)

Yes, but I don't like module names with underscores.

We don't have to decide now though.

>  and pickle
> contain a UserStringIO and UserPickle class.

Ah, yuck. UserThis and UserThat classes are a thing from the past,
when you couldn't subclass the built-in types.

I like what Raymond did with DictMixin though (which should really be
called SequenceMixin) -- if you want to create your own mapping type
*without* inheriting from dict, you can still get a bunch of standard
implementation boilerplate via inheritance. This is what Java does
with AbstractList etc.

> Alternatively, they could
> be moved wholesale into a python_types module, where we collectively
> maintain Python versions of *all* Python types, including lists and
> tuples.

Sorry, another bad idea. The hope of having a comprehensive collection
of *all* "standard" types is misguided. Types should go in the
appropriate module given their application area. There are tons of
types that don't have global names and don't need them (e.g. various
iterators).

> IOW, I do argue for keeping the Python code somehow, and keeping them
> officially maintained.  Obviously it gets a little absurd with lists and
> numbers, for example, but I think that showing off good use of __new__
> would be a Good Thing.

I'm in agreement with the sentiment of keeping the Python code though
-- it's incredibly useful for example in Jython and IronPython.
Perhaps we should switch to a naming scheme where we have a "pickle"
module that you're supposed to import, which dynamically tries to
import first "_pickle" and if that fails imports "_pypickle" (or some
such naming scheme). If you specifically need to use one or the other
you can import it explicitly (assuming it exists). This is a bit
similar to how we have os.path and posixpath (although the decision
regarding which one os.path refers to is different).

--
--Guido van Rossum (home page: http://www.python.org/~guido/)