1

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?

Dave Abrahams
  • 7,416
  • 5
  • 31
  • 19

2 Answers2

2

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

Community
  • 1
  • 1
ncoghlan
  • 40,168
  • 10
  • 71
  • 80
1

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.

orlp
  • 112,504
  • 36
  • 218
  • 315