This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author pitrou
Recipients Arfrever, ajaksu2, doko, dugan, eric.araujo, loewis, nyb, pitrou, r.david.murray
Date 2011-01-03.19:43:44
SpamBayes Score 5.923463e-09
Marked as misclassified No
Message-id <1294083821.3703.5.camel@localhost.localdomain>
In-reply-to <1294083466.7.0.360526440399.issue1674555@psf.upfronthosting.co.za>
Content
Le lundi 03 janvier 2011 à 19:37 +0000, R. David Murray a écrit :
> Or another idea: change site so that it does not execute on import,
> but instead the machinery that currently imports test site runs a
> 'setup' function after it does the import.

I'm not sure this means anything :) Importing a module automatically
entails running its top-level code (that's the only way it can create
functions, classes, etc.).

However, I agree that in the default site.py, we could stop calling
main() at the top-level and instead call it from the importing code.

> Of course, this would break all the custom site.py's out there, so it
> is probably a non-starter of an idea.

Are there many of them? And usually, you would take the original site.py
and modify it a little. Starting from scratch sounds crazy.

> In the meantime, test___all__ could perhaps be made more robust in the
> face of import errors/warnings for those few modules that import from
> external libraries (xml, logging...anything else?)

Well, ideally, these modules should stop importing external libraries
implicitly. Give them a dedicated function for that instead, that the
user can call if they want to.
History
Date User Action Args
2011-01-03 19:43:50pitrousetrecipients: + pitrou, loewis, doko, nyb, ajaksu2, dugan, eric.araujo, Arfrever, r.david.murray
2011-01-03 19:43:44pitroulinkissue1674555 messages
2011-01-03 19:43:44pitroucreate