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

[Charles Merriam]

I agree.  A wiki page for "leaving just the head of the snake" would
be the correct solution.

On Feb 4, 2008 4:34 PM, Jim Jewett <jimjjewett at gmail.com> wrote:
> 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
>