On Fri, 19 Aug 2016 at 14:11 Chris Angelico <ros...@gmail.com> wrote:
> On Sat, Aug 20, 2016 at 5:33 AM, Brett Cannon <br...@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? Anything is doable given enough time and effort. ;) As of right now the only way is with -S. > If not, can 'make test' somehow hack out site-packages? > The problem is you're dealing with startup which means it won't come into effect until it's too late.
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
