RichTraceback assumes Template was from a file

[sqlalchemy-bot]

Migrated issue, originally created by Anonymous

I realized I had some old tests for exceptions.py that I never submitted -- turns out they don't work because RichTraceback assumes the error occured on a template that was read from a file.

i.e. it gets the filename to read the source code (incase html_error_template wants it). But in a case like:

Template("test")

there is no filename

======================================================================
ERROR: test the html_error_template
----------------------------------------------------------------------
Traceback (most recent call last):
  File "exceptions.py", line 22, in test_html_error_template
    html_error = exceptions.html_error_template().render()
  File "/beans/home/pjenvey/src/python/mako/lib/mako/template.py", line 109, in render
    return runtime._render(self, self.callable_, args, data)
  File "/beans/home/pjenvey/src/python/mako/lib/mako/runtime.py", line 287, in _render
    _render_context(template, callable_, context, *args, **_kwargs_for_callable(callable_, data))
  File "/beans/home/pjenvey/src/python/mako/lib/mako/runtime.py", line 304, in _render_context
    _exec_template(inherit, lclcontext, args=args, kwargs=kwargs)
  File "/beans/home/pjenvey/src/python/mako/lib/mako/runtime.py", line 337, in _exec_template
    callable_(context, *args, **kwargs)
  File "memory:0x83efeec", line 26, in render_body
  File "/beans/home/pjenvey/src/python/mako/lib/mako/exceptions.py", line 71, in __init__
    self.source = file(self.error.filename).read()
TypeError: coercing to Unicode: need string or buffer, NoneType found

[sqlalchemy-bot]

Michael Bayer (@zzzeek) wrote:

yeah so along with the encoding being sent to CompileException / SyntaxException, both take place in the context of a Lexer, and since they are already being passed filename and position should probably contain a reference to the source text.

so that would allow #37 and #38 to both get the source, as a unicode object (no encoding issues) in the same way in the case of these two exceptions. in the case of regular runtime exceptions, we can get at the ModuleInfo for a compiled template which can be enhanced to have all the encoding whatnot available (it has a reference to the generated module, which can have an "_encoding" module-level instance variable present).

can you work up a patch for these things ?

[sqlalchemy-bot]

Michael Bayer (@zzzeek) wrote:

fixed in [changeset:259].

[sqlalchemy-bot]

Changes by Michael Bayer (@zzzeek):

• changed status to closed