Question

When I load my code into epydoc and just load the top module it fails with:

Error: TypeError: 'NoneType' object is not callable (line 10)

Where the the NoneType that it is referring to is a submodule that I tried to load on line 9. How can I get epydoc to explain why it couldn’t load the module on line 9 instead of just plowing ahead and hitting an error?

Per nosko’s request. Here is similar example, where no stack trace is given:

# foo.py
import bar
bar.baz()

# bar.py

def baz():
    print 'baz'

import os
os.environ['DOES_NOT_EXIST']

Run with:

python2.6 epydoc --html foo.py

Produces the less than useful:

    +————————————–

    | In /home/ross/foo.py:

    | Import failed (but source code parsing was successful).

    |     Error: KeyError: ‘DOES_NOT_EXIST’ (line 1)

I want epydoc to tell me that the failure is on line 6 of bar.py. I don’t want it to complain about foo.py‘s import of bar.py. I can’t reproduce my specific problem in a small example, but my fundamental request is that when epydoc fails, I want it to print a stack trace to point to the issue. Whether it is loading a sub-module or calling not finding a key in a dictionary.

NOTE: The root of this problem is that the code I am trying to document is an input to SCons which has different environment setup issues. That’s why when I run in epydoc it doesn’t work, but the script still works when run with scons -f SConstruct.py. I’m also trying to generate documentation with sphinx. When I run with sphinx it actually shows the stack trace. Maybe I’ll go with sphinx…

Answer 1

So if I understand correctly, the module you’re running epydoc on imports a module that has an error in it (not the module you want to generate docs for)?

If all you need to accomplish is to see the line in the file which has the error so you can debug it, you can pass in this file as well and the line number where the error occurred will be listed for that module.

So, running:

epydoc --check foo.py bar.py

Will output:

+------------------------------------------------------------------------------------------------------------
| In /home/mark/Desktop/foo.py:
| Import failed (but source code parsing was successful).
|     Error: KeyError: 'DOES_NOT_EXIST' (line 2)
|   
+------------------------------------------------------------------------------------------------------------
| In /home/mark/Desktop/bar.py:
| Import failed (but source code parsing was successful).
|     Error: KeyError: 'DOES_NOT_EXIST' (line 7)
|   

Since Bar.py is also analyzed, the line number where the error occurred in this file is listed.

Now, if you’re looking for a more robust solution because this is a common problem you need to deal with then you’re going to have to start hacking the epydoc internals. Having done so myself, I’d advise you to avoid running down this rabbit hole if you can. If switching to Sphinx is an option, I’d recommend this route.