Neil Schemenauer wrote: > Introduce a lazy module import process that modules can opt-in to. > The opt-in would either be with a __future__ statement or the > compiler would statically analyze the module and determine if it is > safe. E.g. if the module has no module level statements besides > imports.
and `def` and `class` of course. There are a few other things that might end up marking a module as "industrious" (my thesaurus's antonym for "lazy"). There will likely be assignments of module global such as: MY_CONST = 'something' and it may even be a little more complicated: COLORS = dict( red=1, blue=2, green=3, ) REVERSE = {value: key for key, value in COLORS.items()} A naive evaluation of such a module might not notice them as lazy, but I think they could still be treated as such. Function and class decorators might also be false positives. E.g. @public def my_public_function(): pass or even @mungify class Munged: pass Maybe that's just the cost of doing business, and if they clear the lazy flag, so be it. But it feels like doing so will leave quite a bit of lazy loading opportunity left on the table. And I'm not sure you can solve all of those by moving things to a module level __init__(). Cheers, -Barry _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/