This is unrelated to issue 10517 (based on Dave Malcolm's initial investigation, that looks like it may be a genuine problem in multiprocessing)

Instead, this relates to a problem in concurrent.futures where it installs a logging *handler* as a side effect of import. IMO, this is itself a bug in the concurrent.futures package - the standard library shouldn't be installing logging handlers implicitly, but only when explicitly asked to do so, or when absolutely necessary (multiprocessing is an example of a package that walks this line appropriately).

The reason the test_pydoc, test_logging, test_concurrent_futures sequence causes an error is as follows:

1. test_pydoc walks the entire package hierarchy when testing its ability to generate the HTML for the search page.
2. this implicitly imports concurrent.futures, since it is implemented as a package that imports names from submodules in __init__.py
3. this means the c.f handler is already registered in logging when test_logging is run
4. as test_logging assumes it has full control over the logging state, the c.f handler is not left in the same state as it started in
5. test_concurrent_futures then fails, as it assumes the state of the handler has not changed since it was created as a side-effect of the package import

Quite a trip down the rabbit hole to figure that one out :)

Handing back to Brian to fix the underlying problem (i.e. the implicit installation of the logging handler by concurrent.futures).

Georg FYI as to why the py3k buildbots will sometimes go red if the randomised execution happens to run these 3 tests in this particular order (and my apologies for checking in the regrtest.py changes during the release freeze).