On Mon, 7 Jun 2010 14:20:41 -0500

Ian Bicking <ianb@colorstudy.com> wrote:

> On Mon, Jun 7, 2010 at 1:52 PM, Antoine Pitrou <solipsis-xNDA5Wrcr86sTnJN9+BGXg@public.gmane.org> wrote:
>
> > > I say there is consensus because as far as I know anything substantial
> > has a
> > > maintained version outside the standard library; argparse is implicitly,
> > > unittest is unittest2, ElementTree always has maintained a separate
> > > existence, simplejson implicitly.
> >
> >
> > "Anything substantial" is more than exagerated. The modules you are
> > mentioning are exceptions, two of which may even be temporary (argparse
> > and unittest2). Most sdtlib modules don't have external releases, and
> > many of them are still "substantial".
> >
>
> Most other modules are very old.

Well, even if that's true (I haven't checked and I guess we wouldn't
agree on the meaning of "old"), so what?
I guess what I'm asking is: what is your line of reasoning?
You started with a contention that:

“There is no reason any new library or functionality should be tied to a
Python release”

and, in my humble opinion, you failed to demonstrate that. In
particular, you haven't replied to my argument that it
dramatically eases dependency management.

It only eases dependency management in closed systems with a fixed Python version. If you support more than one Python version than you still have dependency management, it is just tied to ad hoc workarounds when there are compatibility problems, or ignoring new functionality.

The importance of "old" vs. "new" modules is that people tend to have a lowest version of Python they support, as simply a hard stop. This is currently Python 2.5 for most people, 2.4 for some groups (and just a very few stragglers with 2.3). So long as you never use anything beyond what 2.5 provides then it's okay, which is most of the standard library. I am not aware of anything added since 2.5 that isn't backported or previously available as a separate library (I'm sure there's *something*, just nothing I can think of).

There is no clear policy about how backports are managed. There's some disfavor for backporting under the same name (PyXML being a primary source of this disfavor), but implicitly argparse *will* be backported as such as it is already installed under argparse and that name matches the stdlib name. It's unclear what should happen when you install a backport in a version of Python that already has the module. E.g., if distutils2 is distributed as distutils2 it would be able to override the standard library when installed unless there was code specifically to disallow it.

Also we have implicit dependency management and versioning already because a few libraries in the standard library have .egg-info files installed.