I don't feel it's my job to accept or reject this PEP, but I do have an opinion.

The scope of the PSF organization is far beyond just the Python language -- it includes the Python developer community, the Python user community, 3rd party Python packages and their communities (even if some have created their own organizations). But I think that it is "scope creep" to try and be "pure" in our tooling or workflows.

Python has a long history (all the way back to my choice of a MIT-style license for the first release) of mixing "free" and "non-free" uses and tools -- for example on Windows we consciously chose to align ourselves with the platform tooling rather than with the (minority) free tools available, Python has been ported to many commercial platforms, and I've always encouraged use of Python in closed-source situations.

I bring this up to emphasize that (unlike GNU software and the FSF) Python has no additional hidden agenda of bringing freedom to all software. At least that's how I feel about it -- clearly some of the most vocal contributors to this thread feel differently.

Now some entirely practical points.

- I am basically the only remaining active PEP editor, so I see most PEP contributions by non-core-committers. Almost all of these uses github. Not bitbucket, not some other git host, but github. I spend a fair amount of time applying patches. It would most definitely be easier if I could get them to send me pull requests.

- I am not worried about "lock in". The most important stuff is copied in the local git repos of hundreds of core devs and thousands of others. Pull requests are by nature short-lived -- and if you really want a history of the back-and-forth that led to the eventual set of diffs that was integrated, you could subscribe a mailing list to it to archive it. I'm sure there's a way to back up the issue tracker too.

Finally. And this may actually be the most important point. Python people should be doing stuff that makes Python better (both taken in the most inclusive way possible). For stuff that's not unique to Python but can be used by many other open-source projects, such as compilers, DVCS tools, or mailing lists, we should not be wasting our precious time on building and maintaining our own tools or administering the servers on which they run. And historically we've not done a great job on maintenance and administration.

Of course it's fun to make tools in Python, and to see them used beyond the Python world. But that's an entirely different argument from what I hear.

--Guido van Rossum (python.org/~guido)