如何从 Python 回溯中消除自定义 __import__ 钩子
我是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 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
你可以,但你也不应该(当主模块通过
-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
并非没有严重破坏该语言。我不推荐这样做,还因为隐藏堆栈跟踪的一部分通常是一个坏主意。特别是如果模块的一部分引入了意外错误。
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.