I think I have figured this out, thanks for your input.
The time comes from lazy modules related to e-mail importing on
attribute access, which is acceptable. Hence of course
why ImportError was sometime raised.
I originally was thinking that accessing __file__ was triggering some
mechanism that
En Fri, 05 Jun 2009 00:12:25 -0300, John Machin sjmac...@lexicon.net
escribió:
(2) This will stop processing on the first object in sys.modules that
doesn't have a __file__ attribute. Since these objects aren't
*guaranteed* to be modules,
Definitely not guaranteed to be modules. Python
Sorry, there is a typo. The code should read as below to repro the problem:
for module in sys.modules.itervalues():
try:
path = module.__file__
except (AttributeError, ImportError):
return
En Thu, 04 Jun 2009 22:24:48 -0300, Zac Burns zac...@gmail.com escribió:
The section of code below, which simply gets the __file__ attribute of
the imported modules, takes more than 1/3 of the total startup time.
Given that many modules are complicated and even have dynamic
population this
On Fri, 05 Jun 2009 02:21:07 +, Steven D'Aprano wrote:
You corrected this to:
for module in sys.modules.itervalues():
try:
path = module.__file__
except (AttributeError, ImportError):
return
(1) You're not importing anything inside the
Zac Burns wrote:
The section of code below, which simply gets the __file__ attribute of
the imported modules, takes more than 1/3 of the total startup time.
Given that many modules are complicated and even have dynamic
population this figure seems very high to me. it would seem very high
if one
