Could we summarize in few words?
| DEBUG (development) | not DEBUG (production)
TEMPLATE_DEBUG | raise TemplateSyntaxError | ?
not TEMPLATE_DEBUG| ? | ?
On Sat, Jul 9, 2011 at 12:53 PM, Tai Lee wrote:
>
>
> On Jul 9, 12:24 pm, Kar
On Jul 9, 12:24 pm, Karen Tracey wrote:
> I'm strongly against that idea. Swallowing errors makes it incredibly
> difficult to debug errors. I would prefer for the `TEMPLATE_DEBUG` setting to
> turn off much of the error-silencing currently done in template processing.
> Yes, that means differen
On Fri, Jul 8, 2011 at 9:55 PM, Tai Lee wrote:
> Secondly, there is the inconsistent behaviour between production and
> development environments related to the `TEMPLATE_DEBUG` setting. I
> think that if an exception is intentionally silenced in production, it
> should also be intentionally silen
On Jul 8, 11:31 pm, Jacob Kaplan-Moss wrote:
> > [...] but some of Django's own template tags (e.g. `widthratio`) don't
> > adhere to
> > this policy.
>
> These are bugs, and should be fixed.
Thanks for this clarification. I will try to review the built-in tags
and submit some patches to fix t
On 07/08/2011 05:24 PM, Jonathan Slenders wrote:
My feeling is that we should silence TypeError, AttributeError and
KeyError in _resolve_lookup, but only when they occur one frame deep.
I agree with what you propose but AFAIK it's not easy to solve without
doing frame analysis (I'd say that fe
Something related I was wondering about...
Errors in templates should be silenced -- I agree with that -- but
only when they are caused by an error in the template.
Variable.resolve can fail silent because that's caused by the template
author, who is referring to non-existing variables.
However,
On Thu, Jul 7, 2011 at 8:37 PM, Tai Lee wrote:
> The docs say that when writing custom template tags, the `render()`
> function should never raise `TemplateSyntaxError`, [...]
This rule is the correct one, and I'm very much against changing it.
> [...] but some of Django's own template tags (e.g
