[Python-Dev] PEP 407 / splitting the stdlib

[Antoine Pitrou]

Le mercredi 18 janvier 2012 à 21:26 +1000, Nick Coghlan a écrit :
> I'm also wholly in agreement with Ezio that using the
> same versioning scheme for both full releases and interim releases is
> thoroughly confusing for users 

It's a straight-forward way to track the feature support of a release.
How do you suggest all these "sys.version_info >= (3, 2)" - and the
corresponding documentation snippets a.k.a "versionadded" or
"versionchanged" tags - be spelt otherwise?

> for example, I consider Red Hat's
> completely separate branding and versioning for Fedora and RHEL a
> better model for end users

It's not only branding and versioning, is it? They're completely
different projects with different goals (and different commercial
support).

If you're suggesting we do only short-term releases and leave the
responsibility of long-term support to another project or entity, I'm
not against it, but it's far more radical than what we are proposing in
the PEP :-)

> Instead, if the proposal involves instituting a PEP 3003 style
> moratorium (i.e. stdlib changes only) for all interim releases, then
> we're essentially talking about splitting the versioning of the core
> language (and the CPython C API) and the standard library. If we're
> going to discuss that, we may as well go a bit further and just split
> development of the two out onto separate branches, with the current
> numbering scheme applying to full language version releases and
> switching to a date-based versioning scheme for the standard library
> (i.e. if 3.3 goes out in August as planned, then it would be "Python
> 3.3 with the 12.08 stdlib release").

Well, you're opposing the PEP on the basis that it's workforce-intensive
but you're proposing something much more workforce-intensive :-)

Splitting the stdlib:
- requires someone to do the splitting (highly non-trivial given the
interactions of some modules with interpreter details or low-level C
code)
- requires setting up separate resources (continuous integration with N
stdlib versions and M interpreter versions, for example)
- requires separate maintenance and releases for the stdlib (but with
non-trivial interaction with interpreter maintenance, since they will
affect each other and must be synchronized for Python to be usable at
all)
- requires more attention by users since there are now *two* release
schedules and independent version numbers to track

The former two are one-time costs, but the latter two are recurring
costs.

Therefore, splitting the stdlib is much more complicated and involved
than many people think; it's not just "move a few directories around and
be done".
And it's not even obvious it would have an actual benefit, since
developers of other implementations are busy doing just that (see Jeff
Hardy's message in this thread).

Regards

Antoine.