I'm having the same problem. The problem seems to be that
help("modules") iterates through all the modules, loading each one in
turn, and if any one of them is broken then the iteration will fail,
without a sensible indication of where the failure occurred.
As an alternative method of listing all the modules I've tried
from pydoc import apropos
apropos(None)
This still fails, but at least it gives a partial list of modules
prior to failing.
so I got a list ending with
...
_yaml
anyjson
appindicator
I uninstalled appindicator, in case that was the problem, but it
wasn't. So I looked for something which came closely after
appindicator alphabetically, found python-apport, and uninstalled
that. Now apropos gets much further, but it still fails, this time at
gufw.model, suggesting that the next problematic module comes
alphabetically shortly after gufw.
I could keep uninstalling modules until pydoc.apropos or
help("modules") works, but all these modules are presumably there for
a reason. For instance, when I uninstalled python-apport, I think the
Ubuntu-One control panel got uninstalled as a dependency. In any case,
having a command which is so fragile that it can be broken by any
fault at all, anywhere in the entire system, doesn't seem to me to be
a sensible design. There has to be a way of listing modules without
loading every module.
Martin Gradwell
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
