After reviewing the pull request, I wonder if it would be better to raise 
exceptions when comparing nonexistent variables in {% if %} rather than 
altering the behavior. For existing projects, this would prevent possible 
inadvertent information leakage if some {% if %} starts evaluating 
differently than it did before. While the current behavior may not be 
documented, it seems risky to silently change it.

There are examples of that behavior change on the PR:

On Saturday, January 7, 2017 at 12:21:33 PM UTC-5, Tim Martin wrote:
> On Friday, 6 January 2017 10:15:22 UTC, Alasdair Nicol wrote:
>> Hi,
>> On Thursday, 5 January 2017 17:51:39 UTC, Tim Martin wrote:
>>> On Thursday, 5 January 2017 04:15:31 UTC, Carl Meyer wrote:
>>>> Hi Tim, 
>>>> On 01/04/2017 03:39 PM, Tim Martin wrote: 
>>>> > 1) There are test cases where we have templates that should treat "x 
>>>> >    is y" as True where x and y are both undefined. 
>>>> Really? Is this an accidental side effect of some historical change, or 
>>>> really the intent of the test? That behavior seems buggy to me; more 
>>>> likely to be a bug-magnet than useful. 
>>> There are a couple of test cases in 
>>> test_if_is_both_variables_missing and 
>>> test_if_is_not_both_variables_missing. These are verifying this specific 
>>> case, so they haven't been introduced by accident. I haven't got as far as 
>>> figuring out whether it was a fully thought through decision or whether 
>>> someone just created these cases for completeness.
>> I added the tests in ticket 26479 (see comment 5 onwards) [1]. I believe 
>> I added them for consistency with == and != operators, which have similar 
>> tests [2], [3] (trickier to spot because they are numbered). I apologise if 
>> adding the tests has made it harder to improve the behaviour of the tag. 
> Thanks for the background info Alasdair, that saved me lots of time 
> hunting around.
> I agree you were right to add the tests, which were useful since without 
> them I wouldn't have realised the potential behaviour change I was 
> introducing. As I see it, these tests don't in themselves form a reason not 
> to change the behaviour (since AIUI you originally added them for 
> completeness, rather than because this specific behaviour was desired).
> Does anyone think changing the behaviour of {% if a is None %} is the 
> wrong thing to do? I realise there can potentially be template code out 
> there relying on this, but after a quick scout through the documentation I 
> can't see anywhere that the behaviour on undefined variables is specified 
> officially.
> For what it's worth, the same issue doesn't come up with ==, because 
> although the existing template behaviour has the same pattern, it's 
> possible to override == and != so that the Undefined object gives the same 
> behaviour as None did before. It's only for 'is' that this can't be 
> achieved. I don't know how for to go with this: preserving the existing == 
> behaviour but changing it for 'is' leaves the two operations superficially 
> inconsistent (though there's nothing fundamentally wrong with two things 
> that satisfy equality but not 'is'). I can see a couple of alternatives (in 
> all cases all variables are undefined):
> * "x is y" is false, but "x == y" is true and "x != y" is false (minimal 
> difference from the current behaviour)
> * "x is y" and "x == y" are both false, "x != y" is true (probably the 
> most mutually consistent?)
> * "x is y", "x == y" and "x != y" are all false (the SQL NULL alternative 
> - I'm not sure if I like this, but it has the merit that wrongly skipping 
> sections of a template is usually less bad than wrongly including parts of 
> a template)
> Tim

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