Found the bug.
It's in Mako, dealing with a traceback that contains a closure (any
decorated function).
When it lists the backtrace, like:
('/home/wacky/build/Vigilia/env/lib/python2.6/site-packages/pylons/controllers/core.py',
105,
'_inspect_call',
'result = self._perform_call(func, args)'),
('/home/wacky/build/Vigilia/env/lib/python2.6/site-packages/pylons/controllers/core.py',
57,
'_perform_call',
'return func(**args)'),
('<string>', 2, 'edit_album', None),
('/home/wacky/build/Vigilia/vigilia/lib/base.py',
88,
'wrapper',
'return func(self, *args, **kwargs)'),
notice the <string>, 'edit_album', and None object. This None object is the
cause. It should be converted to string, or Mako should know how to deal
with it.
We get a None there when the function is a closure, or a returned function
that dynamically generated, which is the case with most decorators.
The solution is a two-liner:
diff -r d51e9106731b mako/exceptions.py
--- a/mako/exceptions.py Tue Apr 13 10:07:04 2010 -0400
+++ b/mako/exceptions.py Sat Apr 17 16:28:52 2010 -0400
@@ -152,6 +152,8 @@
rawrecords = traceback.extract_tb(trcback)
new_trcback = []
for filename, lineno, function, line in rawrecords:
+ if not line:
+ line = ''
try:
(line_map, template_lines) = mods[filename]
except KeyError:
Just hope someone from the Mako team sees this.
Hope this helps,
Alexandre Bourget
Savoir-faire Linux inc.
On Sat, Apr 17, 2010 at 12:26 PM, Alexandre Bourget <a...@bourget.cc> wrote:
> Same problem here.
>
> Seems to me it's a Mako related exception handling bug. It stalls in it's
> mako/exception.py file when a `line` is None..
>
> Was this solved or reported to the Mako guys ?
>
> thanks
>
> Alexandre
>
>
> On Fri, Apr 16, 2010 at 2:06 PM, Mike Orr <sluggos...@gmail.com> wrote:
>
>> On Fri, Apr 16, 2010 at 10:22 AM, kazin <richka...@gmail.com> wrote:
>> >> I'm going to go try recreating the whole app and copying over my
>> >> changes to see if I can track where it goes astray.
>> >
>> > My problem was caused by me adding a @nocache decorator to the
>> > BaseController's __call__method. As soon as that was removed,
>> > Template errors started appearing again.
>> >
>> > I must have screwed up when I tested removing it before.Sorry for the
>> > trouble, and thanks for the help!
>>
>> Still, does this mean there's a bug? Shouldn't errors pass through
>> @nocache cleanly?
>>
>> I guess it depends on whether it's reasonable to put @nocache on the
>> base controller, and that I don't know because I don't use it. If
>> somebody thinks it should work, and can confirm it's not behaving
>> properly in the case of missing template variables, please open a bug
>> ticket for it.
>>
>> --
>> Mike Orr <sluggos...@gmail.com>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "pylons-discuss" group.
>> To post to this group, send email to pylons-disc...@googlegroups.com.
>> To unsubscribe from this group, send email to
>> pylons-discuss+unsubscr...@googlegroups.com<pylons-discuss%2bunsubscr...@googlegroups.com>
>> .
>> For more options, visit this group at
>> http://groups.google.com/group/pylons-discuss?hl=en.
>>
>>
>
--
You received this message because you are subscribed to the Google Groups
"pylons-discuss" group.
To post to this group, send email to pylons-disc...@googlegroups.com.
To unsubscribe from this group, send email to
pylons-discuss+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en.
