如何从 Python 回溯中消除自定义 __import__ 钩子

发布于 2024-11-04 03:36:25 字数 1532 浏览 5 评论 0原文

我是Lazy Python Reloader的实现者,它一切都工作得很好,除了一旦我覆盖了内置 __import__ 函数,每当加载模块出现错误时,我就开始在回溯中看到我的替换。例如,下面有两个 _real_import 实例,这只是一种干扰 - 它们只是调用内置导入函数:

 File "/Library/Python/2.6/site-packages/buildbot-0.8.4_pre_521_gea039fa-py2.6.egg/buildbot/master.py", line 207, in do_load
    exec f in localDict
  File "/Users/dave/src/fossbot-top/master.cfg", line 13, in <module>
    from fossbot import *
  File "/Library/Python/2.6/site-packages/lazy_reload.py", line 83, in _lazy_reload_import
    m = _real_import(name, globals, locals, fromlist, level)
  File "/Users/dave/src/fossbot-top/fossbot/__init__.py", line 22, in <module>
    projects = 'fossbot.projects'
  File "/Users/dave/src/fossbot-top/fossbot/bbot/__init__.py", line 24, in master
    for m in load_submodules(projects):
  File "/Users/dave/src/fossbot-top/fossbot/bbot/util.py", line 30, in load_submodules
    ret.append(_import(parent_module_name+'.'+submodule_name))
  File "/Users/dave/src/fossbot-top/fossbot/bbot/util.py", line 4, in _import
    __import__(module_name)
  File "/Library/Python/2.6/site-packages/lazy_reload.py", line 83, in _lazy_reload_import
    m = _real_import(name, globals, locals, fromlist, level)
  File "/Users/dave/src/fossbot-top/fossbot/projects/el_get.py", line 13, in <module>
    build_procedures=[GitHubElisp('dimitri/el-get')] + 1

有谁知道是否有一种方法用于 lazy_reload 在生成这些帧时从回溯中消除这些帧?

I'm the implementor of the Lazy Python Reloader, and it's all working wonderfully, except that once I overrode the builtin __import__ function, I started seeing my replacement in tracebacks whenever there was an error in a module being loaded. For example, there are two instances of _real_import in the following, that are just a distraction—they're just calling through to the builtin import function:

 File "/Library/Python/2.6/site-packages/buildbot-0.8.4_pre_521_gea039fa-py2.6.egg/buildbot/master.py", line 207, in do_load
    exec f in localDict
  File "/Users/dave/src/fossbot-top/master.cfg", line 13, in <module>
    from fossbot import *
  File "/Library/Python/2.6/site-packages/lazy_reload.py", line 83, in _lazy_reload_import
    m = _real_import(name, globals, locals, fromlist, level)
  File "/Users/dave/src/fossbot-top/fossbot/__init__.py", line 22, in <module>
    projects = 'fossbot.projects'
  File "/Users/dave/src/fossbot-top/fossbot/bbot/__init__.py", line 24, in master
    for m in load_submodules(projects):
  File "/Users/dave/src/fossbot-top/fossbot/bbot/util.py", line 30, in load_submodules
    ret.append(_import(parent_module_name+'.'+submodule_name))
  File "/Users/dave/src/fossbot-top/fossbot/bbot/util.py", line 4, in _import
    __import__(module_name)
  File "/Library/Python/2.6/site-packages/lazy_reload.py", line 83, in _lazy_reload_import
    m = _real_import(name, globals, locals, fromlist, level)
  File "/Users/dave/src/fossbot-top/fossbot/projects/el_get.py", line 13, in <module>
    build_procedures=[GitHubElisp('dimitri/el-get')] + 1

Does anyone know if there's a way for lazy_reload to eliminate those frames from backtraces when they are generated?

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

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

发布评论

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

评论(2

风流物 2024-11-11 03:36:25

可以,但你也不应该(当主模块通过-m 开关)。当异常一直逃逸到程序的顶层时,很难提前确切地知道哪些组件出现了故障(并且正在进行重新加载的事实很可能是重要的)。

如果您仍然想继续沿着这条路走下去,我建议您首先看一下:
如何修改 Python 回溯对象 然后在Jinja2

代码中尝试使模板代码产生准确的回溯(上述问题答案中的链接已过时):
https://github.com/mitsuhiko/jinja2/blob/master/ jinja2/debug.py

You can but you also shouldn't (even the standard library's runpy module leaves itself in the stack trace when the main module is executed via the -m switch). When an exception escapes all the way to the top level of a program, it's hard to know in advance exactly which components were at fault (and the fact that reloading is going on has a high chance of being significant).

If you still want to continue down that path, I suggest first taking a look at:
How can I modify a Python traceback object when raising an exception?

And then at the Jinja2 code which tries to make the templating code produce accurate tracebacks (the link in the answers to the above question is out of date):
https://github.com/mitsuhiko/jinja2/blob/master/jinja2/debug.py

猫卆 2024-11-11 03:36:25

并非没有严重破坏该语言。我不推荐这样做,还因为隐藏堆栈跟踪的一部分通常是一个坏主意。特别是如果模块的一部分引入了意外错误。

Not without severely hacking the language. I wouldn't recommend this, also because it's usually a bad idea to hide a part of a stack trace. Especially if a part of your module introduces an unexpected error.

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