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.
On Saturday, February 25, 2017 at 9:54:10 AM UTC-5, Tim Martin wrote:
>
> Actually, I can imagine that the option might be worth keeping
> permanently. I think both the "exception on use of undefined" and "treat
> undefined as different from all other objects" would both be valid modes.
> Treating undefined as None is probably only justifiable for backward
> compatibility, though. I'll rework the patch to support a setting unless
> anyone comes up with a better idea.
>
> I'm not sure I like the proposal of throwing an exception on `if` but not
> in other cases. It seems more consistent to just raise an exception on any
> use of an undefined variable.
>
> Tim
>
> On Monday, 20 February 2017 11:54:37 UTC, Marc Tamlyn wrote:
>>
>> +1 to not having to add (and then remove later) a {% load %} tag to every
>> template - that was seriously dull with the URL change.
>>
>> Marc
>>
>> On 20 February 2017 at 11:42, Luke Plant <l.pla...@cantab.net> wrote:
>>
>>> On 19/02/17 12:55, Adam Johnson wrote:
>>>
>>> +1 for more obvious errors, silently changing the behaviour could indeed
>>> lead to unconsidered security holes like
>>>
>>> {% if user is None %}
>>> non-sensitive information
>>> {% else %}
>>> sensitive information
>>> {% endif %}
>>>
>>> ...which doesn't seem like an unrealistic template snippet. We all know
>>> variables can go missing in refactorings.
>>>
>>> Another option, perhaps not feasible to implement, would be deprecating
>>> the old behaviour, similar to the previous change in url with something
>>> like:
>>>
>>> {% load undefined_vars from future %}
>>>
>>>
>>> I agree there are a lot of potential security/correctness issues with
>>> this, it is potentially quite a big change (though very helpful IMO).
>>>
>>> A different approach to introducing it might be a setting, possibly an
>>> option to the Django template engine instead -
>>> https://docs.djangoproject.com/en/1.10/ref/settings/#std:setting-TEMPLATES-OPTIONS
>>>
>>> . I think this would be more appropriate for something that is more of a
>>> global behaviour issue, more practical than having to add hundreds of 'load
>>> from future' tags, plus it would then parallel other similar settings like
>>> 'string_if_invalid'. In the next version of Django the option would default
>>> to False (i.e. old behaviour), but raise a deprecation warning, in future
>>> versions it would simply be True, and raise an error if someone tries to
>>> pass False (but allow True, for the sake of apps that are spanning multiple
>>> Django versions).
>>>
>>> This would allow people to test their site with the new mechanism and
>>> have time to fix issues, which can be especially important for 3rd party
>>> Django apps.
>>>
>>> Ideally there would be some way to instrument code and see if the output
>>> would be different with the new behaviour, but I can't think of an easy way
>>> to do this.
>>>
>>> Luke
>>>
>>> --
>>> 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 django-develop...@googlegroups.com.
>>> To post to this group, send email to django-d...@googlegroups.com.
>>> Visit this group at https://groups.google.com/group/django-developers.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/django-developers/496fa4a8-b902-657a-92c2-9766bfff8a26%40cantab.net
>>>
>>> <https://groups.google.com/d/msgid/django-developers/496fa4a8-b902-657a-92c2-9766bfff8a26%40cantab.net?utm_medium=email&utm_source=footer>
>>> .
>>>
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
--
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 django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/e32a0ad9-50bf-4b8c-8ac5-1cd9ce2b0eda%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
