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

[Konrad Delong]

On 7 June 2010 22:09, Ian Bicking <ianb at colorstudy.com> wrote:
> 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> 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.

Which gives me an idea:

What if all the backports were managed within a single PyPI package,
(e.g. backport26, backport27) with clear policy on older Python
versions supported.

then I could write in my py2.4 script:

from backport26.os.path import relpath

Konrad