[Python-3000] Is pickle's persistent_id worth keeping?

[Paul Moore]

On 08/01/2008, Fred Drake <fdrake at acm.org> wrote:
> On Jan 8, 2008, at 7:54 AM, J. Clifford Dyer wrote:
> > Aside from the concerns of a few developers wanting simpler release
> > cycles, this is definitely not the way to go.
>
> I don't mean that "political" (in this case, "business") reasons are
> unimportant, but they can be addressed in other ways.

How? Isn't the "business" benefit of the current situation that the
official installer from python.org includes (nearly) all of the basic
tools required for development, without needing additional packages to
be installed as well? [This is for Windows only, which is my concern -
the situation for other platforms isn't something I have any
experience with].

Solutions I've seen offered so far have involved easy download and
installation of spun off packages (not appropriate - each separate
install has a cost in terms of getting approval) or having optional
"sumo" distributions, from python.org or elsewhere (not likely to be
suitable, as "the official distribution" has a credibility that others
don't, for better or worse).

> The advantage of decoupled release cycles isn't simplicity (though
> that's welcome as well, if attainable), but the ability to update
> library packages independently should bug fixes be needed.

Conversely, there's a risk of dilution of developer effort, and a
resulting *reduction* in frequency of bug fixes. There's no clear
evidence either way.

> I don't think this is a huge deal for the pickle module, but is more
> of an issue for some of the wrappers for external libraries.  The
> database packages (bsddb, sqlite) come to mind here, but aren't the
> only cases where independent releases make sense.

Make sense in what way? I was very happy to see sqlite included in the
stdlib, as it made it part of the standard toolkit I could assume was
present. There was community pressure to add it - where is the
community (not developer!) pressure now to remove it?

>  We've certainly seen that including the "xml" package in the standard library
> was questionable at best (and the tie to PyXML exacerbated that horribly).

Have we? I avoid XML like the plague, but having XML support in the
stdlib is certainly useful for me. The PyXML attempt to allow for an
independent release cycle and/or extended functionality for a core
package didn't work, certainly[1], but I don't recall anyone
complaining that XML support shouldn't be in the stdlib in any form
(after all, community requests for the inclusion of elementtree
resulted in that being added, as well).

Actually, the history so far (sqlite, elementtree, email, unittest)
shows people wanting *more* in the stdlib, rather than less. Has
anyone asked on somewhere like c.l.p, whether trimming the standard
distribution would meet with community support?

Actually, if I think about it, such a change would probably need a PEP
- which should be a fun exercise for whoever writes it. So maybe the
topic should be shelved until a PEP surfaces.

Paul.

[1] This is a good argument for rejecting the recently-raised idea of
stdlib namespace packages which can easily be extended via 3rd
parties. But that's about a mutable stdlib, not about what's *in* the
stdlib.