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

[Antoine Pitrou]

On Mon, 7 Jun 2010 15:09:36 -0500
Ian Bicking <ianb at colorstudy.com> wrote:
> > 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.

We're misunderstanding each other. I'm talking about dependency
management for users (or application developers), you seem to be talking
about dependency management for library developers.

As for "ad hoc workarounds" and various "compatibility problems", they
wouldn't disappear if the stdlib became smaller; I have trouble
understanding what kind of solution you think would eliminate these
issues.

> 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.

Yes, and it's the same for external modules too. For example, they will
support Twisted 8.0 and upper. So what's the difference?

> 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).

Really, I'm too lazy to go and read the changelogs, but there
definitely are many improvements that are not available in Python 2.5
and older.

> There is no clear policy about how backports are managed.

That's because, contrary to what you seem to think, external backports
are the exception and not the rule.

Regards

Antoine.