Could you describe your use case in more detail?
On Monday, June 19, 2017 at 5:48:36 PM UTC-4, allejj...@gmail.com wrote:
>
> 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/249bf50a-a82f-41e2-8d24-233e567ca8bc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
