Tim Peters wrote: > [Jim Fulton] > ... > >>No, it won't. For example, suppose foo imports B. B tries to import >>C, but fails. B is now broken, but it is still importable. Actually, >>both foo and B can be imported without errors, even though they are >>broken. > > > Then you're proposing a way for a highly knowledgable user to > anticipate, and partially worm around, that Python leaves behind > insane module objects in sys.modules. No. I'm proposing a way for a Python developer to detect the presence or absence of a module. Hm, perhaps it would be better to provide an API (if there isn't one already) to test whether a module is present. AFAIK, the only way to do it is by trying the import. Unfortunately, the error type alone isn't enough to tell whether the error you caught is due to the error condition you are trying to test. Perhaps providing an API is a better way to go. In general, however, I hate the approach of formatting errors as they are raised, rather than as they are converted to strings. Formatting them earlier is a bit more convenient for the exception-class author, but: - It makes the exception data inaccessible without ugly brittle error parsing hacks, and - It makes error raising more costly, which sometimes matters (e.g. for attribute errors). - It makes I18n harder, as it's hard (impossible?) to translate error messages with embedded data. > Wouldn't it be better to change > Python to stop leaving insane module objects in sys.modules to begin > with? It would make the current situation less icky, but it wouldn't solve the problem I posed. You still wouldn't be able to tell the difference between an absent module and a broken one without a error-parsing hack. I think that not ignoring errors is a good thing even if the errors ignored didn't have side effects. ... > That said, I have no objection to giving ImportError exceptions a > module_name attribute. Cool. I could also live with an API that tests whether a module exists. > My objection is to the idea that it solves the > real problem. It isn't intended to solve broken-module problem. It solves (or, at least addresses) a different problem, but it is certainly exacerbated by the broken-module problem. Jim -- Jim Fulton mailto:jim at zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4