My proposal was only for the use of undefined variables in template tags. I 
didn't realize that the behavior of undefined variables in some tags 
resolving to None is documented, but I still think it's a useful change to 
raise an exception instead. The philosophy that template tags shouldn't 
raise exceptions is more unhelpful than helpful in my experience. I think 
the change would be consistent with the deprecation that starts in Django 
1.11 to change {% include %} not to silencing exceptions and render an 
empty string, for example.

On Saturday, February 25, 2017 at 4:44:30 PM UTC-5, Karen Tracey wrote:
> On Sat, Feb 25, 2017 at 2:10 PM, Tim Graham < 
> <javascript:>> wrote:
>> I think any use of undefined template variables should raise an 
>> exception. In the long run, keeping a setting to allow some other behavior 
>> seems confusing and, considering the case of templates that might be reused 
>> in different projects with different settings, even dangerous.
> I think I'm confused...Django templates have allowed use of undefined 
> variables and documented their use as evaluating to the empty string for as 
> long as I recall. Wouldn't a change to instead raise exceptions be a major 
> backwards-incompatibility?
> said 
> "If you use a variable that doesn’t exist, the template system will insert 
> the value of the TEMPLATE_STRING_IF_INVALID setting, which is set to '' 
> (the empty string) by default."
> has refined that doc to note that the behavior is slightly different in 
> some tags. 
> Are we really considering changing this behavior to now raise exceptions?

You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
To post to this group, send email to
Visit this group at
To view this discussion on the web visit
For more options, visit

Reply via email to