Message95918
I see occasional failures where a broken module prevents "pydoc -k" ("apropos") from working.
Examples of failures (from our downstream bug tracker) are:
https://bugzilla.redhat.com/show_bug.cgi?id=461419 : "pydoc -k" yields "NameError: name 'wglUseFontBitmapsW' is not
defined"
(a broken OpenGL/WGL/__init__.py module)
https://bugzilla.redhat.com/show_bug.cgi?id=447779 : "pydoc turbogears" doesn't work
(broken TurboGears module)
https://bugzilla.redhat.com/show_bug.cgi?id=246212 : "pydoc -k searchterm" MemoryError. permission denied.
(module only intended to be importable as "root" user)
In each case one or more of the many modules on the system are broken, and importing them leads to an exception being
raised that isn't ImportError.
In each case, the exception bubbles up through the pydoc call ands leads to it exiting.
Obviously the broken modules should be fixed, but it seems to me that pydoc could be more robust against this situation.
I'm attaching a simple patch which makes "pydoc -k" more robust against this situation, by silently discarding all
exceptions raised by imported modules.
How does this look?
One downstream bug report requested taking it further:
> Running "pydoc -k" should catch all exceptions while importing modules, and
> display failed modules _after_ all positive keyword matches (not in between).
> It also should redirect stdout/stderr while importing so error message e.a.
> don't clutter up the list of hits.
to deal with broken modules that spew error messages (this was in https://bugzilla.redhat.com/show_bug.cgi?id=461419#c3
); I've seen some do it to stdout and some to stderr.
How does this sound? I can try to update the patch for this too, if this sounds sane to you. |
|
Date |
User |
Action |
Args |
2009-12-02 20:49:32 | dmalcolm | set | recipients:
+ dmalcolm |
2009-12-02 20:49:32 | dmalcolm | set | messageid: <1259786972.24.0.35920903506.issue7425@psf.upfronthosting.co.za> |
2009-12-02 20:49:29 | dmalcolm | link | issue7425 messages |
2009-12-02 20:49:27 | dmalcolm | create | |
|