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

[Ian Bicking]

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

> On Mon, 7 Jun 2010 11:35:16 -0500
> Ian Bicking <ianb at colorstudy.com> wrote:
> >
> > I think there is a general consensus that functionality should not be
> tied
> > to a Python release, but the results are ad hoc.
>
> I disagree with this. Tying new functionality to a Python release
> vastly simplifies dependency management (instead of having to track the
> versions of N external libraries, sometimes with inter-dependencies).
>

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.

> (Most specifically without serious
> > thought about this development process I am pessimistic about an
> > orderly or positive inclusion of distutils2 in packaging workflows.)
>
> Without any discussion of specifics, I find it hard to understand what
> you are concerned about.
>

1. How will distutils2 updates be made available between Python releases?
2. How will distutils2 features be made available in older Python releases?
3. How will old standard library releases of distutils2 be managed?  E.g.,
if pip starts using distutils2, at the time distutils2 ends up in the
standard library there is a version of distutils2 I cannot simply reject as
incompatible, meaning I can't make use of any new features or bug fixes.

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