[core-workflow] What would it take to split the stdlib out into its own git repo?

[Guido van Rossum]

I think Ned strikes the nail on the head. It's a fair burden to keep
the repos in sync. I propose that instead we have some script that can
make a release of just the stdlib for the benefits of other Python
implementations.

FWIW I've got a fair bit of experience using a subrepo for a similar
purpose, using the proposed separation: mypy depends on typeshed and
includes it as a subrepo; but there are other users of typeshed as
well (Google's pytype, as well as PyCharm). I think it's nice that the
mypy history and the typeshed history are separate. Keeping typeshed
up to date when you switch mypy branches is easy enough using a git
hook.

The two places where it breaks down:

First, there's an endless series of "sync typeshed" commits to the
mypy repo. We do these frequently because we have users of mypy (e.g.
Dropbox) who sync with the development head of mypy regularly --much
more often than mypy releases go out-- and who often want improvements
to typeshed as well as improvements to mypy. When using mypy we don't
point it to a separate copy of typeshed --it would too often be out of
sync-- instead we install from mypy's master branch which also syncs
to a recent version of typeshed.

Second, tests. Mypy's tests depend on typeshed, and typeshed's tests
depend on mypy. It's a never-ending nightmare (or rather, death by a
thousand cuts).

In the mypy world we live with this because we really want to
encourage shared ownership of typeshed (and Google's pytype team
reviews and merges a significant number of typeshed PRs and sometimes
brings up concerns when we forget that typeshed doesn't exist just to
support mypy). But for Python I think the situation is just
asymmetric, and separating out the stdlib isn't going to suddenly
level the playing field. So the burden for the core Python devs is not
warranted, IMO.

--Guido