当 epydoc 加载我的代码时,如何从 epydoc 获取堆栈跟踪?

发布于 2024-08-18 11:47:49 字数 1337 浏览 9 评论 0原文

当我将代码加载到 epydoc 并仅加载顶部模块时,它会失败:

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

其中它引用的 NoneType 是我尝试在线加载的子模块9. 如何让 epydoc 解释为什么它无法在第 9 行加载模块,而不是仅仅继续前进并遇到错误?

根据诺斯科的要求。这是类似的示例,其中没有给出堆栈跟踪:

# foo.py
import bar
bar.baz()

# bar.py

def baz():
    print 'baz'

import os
os.environ['DOES_NOT_EXIST']

运行方式:

python2.6 epydoc --html foo.py

产生不太有用的内容:

    +--------------------------------------
    | 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.

注意:这个问题的根源是我试图记录的代码是 SCons 的输入,它具有不同的环境设置问题。这就是为什么当我在 epydoc 中运行时它不起作用,但在使用 scons -f SConstruct.py 运行时脚本仍然有效。我还尝试使用 sphinx 生成文档。当我使用 sphinx 运行时,它实际上显示了堆栈跟踪。也许我会选择sphinx...

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...

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

说谎友 2024-08-25 11:47:49

因此,如果我理解正确的话,您正在运行 epydoc 的模块会导入一个有错误的模块(不是您想要为其生成文档的模块)?

如果您需要完成的只是查看文件中出现错误的行以便进行调试,您也可以传入此文件,并且将列出发生错误的行号 em> 模块。

因此,运行:

epydoc --check foo.py bar.py

将输出:

+------------------------------------------------------------------------------------------------------------
| 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)
|   

由于 Bar.py 也被分析,因此列出了该文件中发生错误的行号。

现在,如果您正在寻找更强大的解决方案,因为这是您需要处理的常见问题,那么您将不得不开始破解epydoc内部结构。我自己也这样做过,所以我建议你尽可能避免掉进这个兔子洞。如果可以选择切换到 Sphinx,我会推荐这条路线。

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.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文