[Python-3000] pickle, cPickle, and the standard library (was Re: [Python-Dev] inst_persistent_id)
Charles Merriam
charles.merriam at gmail.com
Tue Feb 5 23:39:36 CET 2008
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
>
More information about the Python-3000
mailing list