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

Jim Jewett jimjjewett at gmail.com
Tue Feb 5 01:34:21 CET 2008


On 2/4/08, Charles Merriam <charles.merriam at gmail.com> wrote:
> What about a formal dependency plan instead?

> Python would remain 'batteries included', perhaps verging on 'kitchen
> sink included'.

> Those users working to embed Python or work in other situations where
> a large set of available libraries is a problem would have some help
> in cutting down the footprint in an particular installation.  That is,
> one could freely delete some set of libraries and be fairly sure the
> resulting library set would still run.  What was left would be a
> smaller footprint interpreted language, just not 'Python'.

> Under what circumstances is this a poor idea?   "Hard drive space is
> expensive" is not an acceptable argument.

(1)   Many library modules *use* other modules, but don't really
*rely* on them.  Only a little functionality would be lost.  That sort
of roadmap would encourage the functionality to get left out entirely,
and would certainly increase the amount of fallback boilerplate.

(2)  In bureaucratic environments, the libraries are OK because they
are standard; if a more minimal distribution becomes equally standard,
that will cause problems.  (It wouldn't be nearly as bad as taking
them out and requiring downloads, but it would still be a problem,
because of the need to justify the non-minimal version.)

(3)  If storage footprint is important, then it is also important for
deployed applications -- and it becomes awkward if you have to
sprinkle your own code with fallbacks and workarounds in case the
standard library was clipped.

That said, it might be useful if it were kept at unofficial status,
such as a wiki page.

-jJ


More information about the Python-3000 mailing list