(original) (raw)

On Sat, Aug 20, 2016 at 5:33 AM, Brett Cannon <brett@python.org> wrote:
\>> Hmmmmmmm. So the question is, what is this test testing?
\>
\>
\> It's making sure people who work on the modules that are imported during
\> startup don't accidentally add another module dependency to the startup
\> sequence. Since module imports impact startup time we have historically
\> worked hard to minimize import dependencies for startup (hence things like
\> certain functions in the os module doing imports within a function even
\> though we discourage that practice in general).

Fair enough. Which means it probably \*should\* import site, because
that's going to happen on all normal usage. So that still leaves a few
options:

1) Demand that .pth files restrict themselves to what's already
imported. This means startup is still fast even if you have a bunch of
pths. Downside: Third-party code can break Python's rules. Upside:
When they do, it can be reported as a bug, the fixing of which will
improve startup times when that's installed.

2) Change the test to somehow disable .pth execution while keeping the
rest of site.py intact. This gives more consistent test results, but
still is mostly applicable to normal usage.

3) Ignore the problem and assume that the Python test suite will be
run with no site-packages installed. Status quo, basically. Possibly
with some tweaks so running 'make test' ignores site-packages?

Is #2 doable?

If not, can 'make test' somehow hack out site-packages?