But if the current behaviour is left intact it goes against the definitions
of filters like 'default' and 'default_if_none'.
If one reads the code snippet example in the ticket, the exception is
raised even when the filter shouldn't be invoked.
So, for me the correct behaviour should be not raise any exceptions (maybe
a warning could be used) in cases when filters used are 'default' or
'default_if_none', and are applied to a variable with a valid value that
not trigger these filters.
Only we should focus to resolve (or raise VariableDoesNotExiste exception
if applies) the variables in other filters, e.g if we have more chaining
filters with variables like:
Template('{{ foo|default:notreal1|date:notreal2 }}').render(Context({'foo':
'', notreal2: 'as'})).
El lunes, 19 de junio de 2017, 15:10:54 (UTC-3), Tim Graham escribió:
>
> I think that to convince me to change the current behavior, you would have
> to present a compelling use case for relying on nonexistent variables as
> filter arguments. Wouldn't this behavior typically just hide bugs?
>
> On a related note, I proposed removing the logging of undefined template
> variables here:
> https://groups.google.com/d/topic/django-developers/zdULZcmAWNw/discussion
>
> On Saturday, June 3, 2017 at 10:30:51 AM UTC-4, Shai Berger wrote:
>>
>> On Friday 02 June 2017 18:38:47 Vlastimil Zíma wrote:
>> >
>> > Shai: Values are sometimes turned into an empty string in case of
>> > UnicodeDecodeError, see
>> >
>> https://github.com/django/django/blob/master/django/template/base.py#L994-L
>> > 998
>> >
>>
>> That code is within a render() method -- a place where the value is
>> already
>> going to be turned into a string.
>>
>> > IMO invalid variable should behave the same way regardless of whether
>> it's
>> > printed or used as an filter argument.
>> >
>>
>> My point was that rendering makes a difference because it already implies
>> a
>> possible type change.
>>
>> I stand by my earlier position: Changing a filter argument to a string is
>> odd
>> and unexpected and we shouldn't do this. We should either keep raising an
>> exception, or replace the whole filter expression (rather than just the
>> argument) with string_if_invalid. My preference is towards the exception,
>> but
>> I also see the value of failing silently here.
>>
>> Shai.
>>
>
--
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/24b8d540-9149-4d6d-866d-45e06ae89a2a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
