On 3 Jul 2013 05:44, "R. David Murray"
On Tue, 02 Jul 2013 20:31:48 +0200, Pascal Chambon
wrote:
I agree that a module loading should be, as much as possible, "side effects free", and thus shouldn't have temporary errors. But well, in practice, module loading is typically the time where process-wide initialization are done (modifying sys.path, os.environ, instantiating connection or thread pools, registering atexit handler, starting maintenance threads...), so that case has chances to happen at a moment or another, especially if accesses to filesystem or network (SQL...) are done at module loading, due to the lack of initialization system at upper levels.
There may well be a bug that could be/should be fixed here, but...it seems to me that other than the sys.path modifications, doing any of that at module import time has a strong code smell.
Unfortunately it's one of those "Your code is dubious, but so many people do it anyway we should handle it better than we do" cases. We could also be a lot more emphatic about "import side effects are what marks the boundary between a library and a framework. To stay on the library side of that fence provide a 'start' or 'configure' function instead of doing things implicitly on import". Heck, even *defining* library, framework and application would be a good thing. OTOH, it's hard to find motivation to work on improving the handling of things you think people shouldn't be doing in the first place (that's one of the reasons circular import handling has never been made more consistent). (That's not to dismiss the work Pascal's already done - just pointing out why it may sometimes feel like it's difficult to get interest and feedback on things like this). Cheers, Nick.
--David _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe:
http://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com