[Python-Dev] Please stop changing wsgiref on the trunk (original) (raw)

Guido van Rossum guido at python.org
Mon Jun 12 18:43:47 CEST 2006

On 6/12/06, Phillip J. Eby <pje at telecommunity.com> wrote:

At 09:04 AM 6/12/2006 -0700, Guido van Rossum wrote: >IOW I think PEP 360 is an unfortunate historic accident, and we would >be better off without it. I propose that we don't add to it going >forward, and that we try to get rid of it as we can.

4 of the 6 modules in PEP 360 were added to Python in 2.5, so if you want to get rid of it, now would be the time.

I'm all for it.

While I am an enthusiastic supporter of several of those additions, I am not in favor of the special status granted to software contributed by certain developers, since it is a burden for all other developers.

There is an approach that would address this issue and others relating to external packages, but it would require changes to how Python is built. That is, I would propose a directory to contain externally-maintained packages, each with their own setup.py. These packages could be built and installed with Python, but would then also be separately-distributable.

Alternately, such packages could be done using svn:externals tied to specific release versions of the external packages. This idea would address the needs of external maintainers (having a single release history) while still allowing Python developers to modify the code (if the external package is in Python's SVN repository).

Even that is a burden on regular Python developers. For example, when I do "svn up" in the PEPS directory, which has such an arrangement for the docutils, it usually spends (much) more time deciding that there's nothing new in the docutils than it spends on the rest of the update. I also suspect that the external linking will continue to cause a burden for Python developers -- upgrading to a newer version of the external package would require making sure that no changes made by Python developers in the previous release bundle are lost in the new release bundle.

I personally think that, going forward, external maintainers should not be granted privileges such as are being granted by PEP 360, and an inclusion of a package in the Python tree should be considered a "fork" for all practical purposes. If an external developer is not okay with such an arrangement, they shouldn't contribute.

Note: I'm saying "going forward". I'm not saying that this "tough luck" policy should be applied to the packages that have already been accepted; I don't want the PSF to break its work. Although I'd encourage their authors to loosen up.

Perhaps issues like these should motivate us to consider a different source control tool. There's a new crop of tools out that could solve this by having multiple repositories that can be sync'ed with each other. This sounds like an important move towards world peace!

-- --Guido van Rossum (home page: http://www.python.org/~guido/)

More information about the Python-Dev mailing list