[Python-ideas] Moving development out of the standard library

[Ian Bicking]

On Mon, Jun 7, 2010 at 2:56 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:

> On Mon, 7 Jun 2010 14:20:41 -0500
> Ian Bicking <ianb at colorstudy.com> wrote:
> > On Mon, Jun 7, 2010 at 1:52 PM, Antoine Pitrou <
> solipsis-xNDA5Wrcr86sTnJN9+BGXg at public.gmane.org<solipsis-xNDA5Wrcr86sTnJN9%2BBGXg at 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.

-- 
Ian Bicking  |  http://blog.ianbicking.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20100607/fb6469f0/attachment.html>