[Python-Dev] Fix import errors to have data

Tim Peters tim.peters at gmail.com
Tue Jul 27 20:03:36 CEST 2004


[Tim]
>> Sure!  Jim wants to distinguish "absenceness" from "brokenness" for
>> some reason.  It's not clear to my why

[Jim]
> Because a broken module is something that should get fixed.

Maybe I don't know what "broken" means to you then.  To me it means
things like syntax errors, and module initialization code that raises
runtime exceptions.  If I try to import a module with problems like
those, I don't get ImportError, I get the exception (like SyntaxError
or ZereDivisionError) raised by the broken code in the module, and
catching ImportError in the importer doesn't hide those.  Is the only
case you're concerned about of the "A imports B imports C, and B's
attempt to import C raises an ImportError that's passed on to A"
flavor?  I have one nasty example of that on hand:  Python's site.py
tries to import sitecustomize.py, but if the latter contains a bogus
import then site.py suppresses the error, because it treats the
ImportError as meaning "I guess sitecustomize.py doesn't exist --
that's fine".  That one cost me an hour yesterday!  So I'm becoming a
believer <wink>.

> Hiding errors is a bad thing.  It's like using hasattr. :)

No argument there.


More information about the Python-Dev mailing list