IMHO I think it's more consistent with the definition of certain filters
make the system somehow "lazy" and only evaluate filter variables only when
are used.
El jueves, 22 de junio de 2017, 12:15:53 (UTC-3), Tim Graham escribió:
>
> My question is why is it problematic to put "notreal/notreal2" in the
> context, even if they're unused in some situations?
>
> On Wednesday, June 21, 2017 at 12:02:16 AM UTC-4, allejj...@gmail.com
> wrote:
>>
>> # Some examples here for illustrate better my point of view:
>> from django.template import Context, Template
>>
>> # CASE_1: shouldn't raise an exception because 'foo' variable exists in
>> the context and 'default' filter
>> # shouldn't be invoked,
>> Template('{{ foo|default:notreal }}').render(Context({'foo': ''}))
>> #so, the output should be ''
>>
>> # CASE_2: should raise an exception because 'foo' variable not exist in
>> the context and 'default' filter
>> # will be invoked with non existent variable as argument,
>> Template('{{ foo|default:notreal }}').render(Context({})) #so, the
>> output should be the exception VariableDoesNotExist
>>
>> # CASE_3: should raise an exception because although 'foo' variable
>> exists in the context and 'default' filter
>> # shouldn't be invoked, the filter 'center' is called with non existent
>> variable as argument,
>> Template('{{ foo|default:notreal|center:notreal2
>> }}').render(Context({'foo': '', })) #so, the output should be the
>> exception VariableDoesNotExist but for 'notreal2' variable
>>
>> # CASE_4: shouldn't raise an exception because 'foo' variable exists in
>> the context and 'default' filter
>> # shouldn't be invoked and also the filter 'center' is called with
>> existent variable as argument,
>> Template('{{ foo|default:notreal|center:notreal2
>> }}').render(Context({'foo': 'django', 'notreal2':'15' })) #so, the
>> output should be ' django '
>>
>> # and the same reasoning and analogous examples should be derived for
>> 'default_is_none' filter, only having in mind the definition of that filter
>>
>>
>> El lunes, 19 de junio de 2017, 19:58:56 (UTC-3), Tim Graham escribió:
>>>
>>> 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/435b3aa1-14cd-46ce-b2a6-28fc192cce76%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
