[Python-3000] pickle, cPickle, and the standard library (was Re: [Python-Dev] inst_persistent_id)

[Brett Cannon]

On Feb 3, 2008 1:37 PM, Jim Fulton <jim at zope.com> wrote:
>
> On Jan 25, 2008, at 12:07 AM, Guido van Rossum wrote:
>
> > On Jan 24, 2008 8:59 PM, Aahz <aahz at pythoncraft.com> wrote:
> >> On Thu, Jan 24, 2008, Jim Fulton wrote:
> >>>
> >>> I don't know what that means.  I don't know that Jython or
> >>> IronPython
> >>> need to support cPickle. Honestly, I'd be happy to see a *much*
> >>> smaller standard library and, IMO, the standard library doesn't need
> >>> to include pickle or cPickle.
> >>
> >> While it's easy enough to work around, my company would be unhappy if
> >> pickle were removed, and so would my previous company.
> >
> > I don't know why Jim is saying this (*),
>
> I think the standard library is bloated.  I'd much prefer to see a
> leaner standard library that really provides features that are close
> to the language and provide a packaging system that make it easy to
> install other packages as needed.  I think setuptools is a pretty good
> start at this.
>

But we need a solution, not a start. While the stdlib is bloated, it
is being trimmed down in Py3K already. If you want to trim more then
push for stuff to be removed on a module-to-module basis. But going
from "batteries included" to "batteries easily downloaded" is quite a
shift for Python. And as of right now I really don't see how that
level of a shift can be coded, discussed, and put into Py3K before it
is released. Let alone how difficult it would be to get the manpower
lined up to maintain a server that is going to get hammered by module
downloads (PyPI still goes down on occasion and this would just
increase the strain on the server by a good amount).

> > but it's not going to happen.
> > pickle is here to stay. cPickle is a different story; 99% of programs
> > shouldn't be bothered with the choice between the two.
>
> IMO, the programs the people who care about cPickle don't want to
> sacrifice speed to get the same flexibility as pickle. Similarly, I
> don't want to lose pickles flexibility in the interest of unification.
>

Flexibility is not going anywhere; the C implementation is the one
that needs to change. If the speed is not fast enough then patches are
welcome. But I know I am tired of maintaining two test suites, two
sets of docs, explaining to users why they can't subclass stuff from
cPickle, etc. Plus alternative Python implementations should not have
to say "we are incompatible with the stdlib because we don't have
cPickle and its quirks".

-Brett