As much as I'd like variables to raise an error if they cannot resolve, I 
am with Karen here -- the backwards compatibility considerations should 
take priority here. At least we should have a possibility in the templates 
to check if variables are undefined before we start raising exceptions.


On Sunday, February 26, 2017 at 3:37:20 AM UTC+1, Karen Tracey wrote:
> On Sat, Feb 25, 2017 at 8:21 PM, Fred Stluka < 
> <javascript:>> wrote:
>> I agree that use of undefined variables should raise an exception.
>> The incompatibility with previous versions will mostly catch errors
>> that have been going undetected.
> I disagree, unless you are limiting this change specifically to arguments 
> to non-builtin template tags. (Which I thought already raised exceptions, 
> so I'm still confused here as to what change is being proposed.)
> Given the documented behavior of evaluating undefined variables to empty 
> strings its been common practice to use:
> {% if var_that_may_not_exist %}
> ...stuff that should only show when var exists...
> {% endif %}
> or to include {{ var_that_may_not_exist }} somewhere in a template and 
> rely on it evaluating to an empty string. (admin itself was documented as 
> not working correctly if you set the setting to evaluate undefined to 
> something other than empty string).
> Changing either of these now to raise exceptions would be a huge backwards 
> incompatibility going against previously documented behavior.  Please don't 
> do that.
> It may well be friendlier to developers (I've never been a fan of the 
> "templates shouldn't raise exceptions" philosophy) but the fact is for many 
> years now it's been perfectly acceptable to use what might be undefined 
> variables in templates and the behavior has been documented as to how it 
> will work. Changing that now to start raising exceptions would be 
> incredibly unfriendly to existing code that has been written to rely on it. 
> Karen

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