On Wednesday, 1 March 2017 19:52:22 UTC, Luke Plant wrote:
>
>
> This is a really big backwards incompatibility, as far as I can see. It
> means that any filter may now get passed `UndefinedVariable` instead of
> being passed `None` or string_if_invalid. So for example, the following
> template behaves oppositely with your patch, if variable 'missing' is
> undefined:
>
> {% if missing|yesno == "maybe" %}true{% else %}false{% endif %}
>
> There are likely many other filters that will behave differently e.g.:
>
> {{ missing|add:"x" }}
>
> Without the patch, if 'missing' is undefined this returns "x", but with
> the patch it returns "". It's not just builtin filters I'm thinking about,
> it's everyone else's that would also have to be made aware of this new
> false-y value that it will start receiving. This is a really big backwards
> incompatible change, I don't see how we could justify this. If we were
> starting from scratch it would be another matter.
>
Yes, I can see the issue and I'm open to the idea of abandoning this patch.
If we're not willing to tolerate substantial changes to the behaviour then
I don't think there's a way forward with this patch - changing the
semantics of undefined variables is pretty much the whole point of it.
In fairness, it's possible to change all the built-in filters to preserve
existing behaviour (I've already done it for everything that's documented
or covered by unit tests, though I guess I missed 'yesno', which should
clearly return maybe for an undefined variable) and any third-party filters
that are relying on the semantics of undefined variables (outside of 'if',
'for' and 'regroup') are based on undefined behaviour. Imposing changes on
third-party filters in a major release of Django doesn't seem too
unreasonable. But I don't know that there's a strong enough positive case
for making the change. I don't care much about it, I only picked up this
bug because it looked like an easy way to learn the template system.
For the record, I don't like the design of treating undefined values as
None, and I really don't like the design of them having different values in
different contexts. But I guess that's the design we're stuck with.
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 [email protected].
To post to this group, send email to [email protected].
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/c5b64d00-40c4-404e-9960-c7ac21251061%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
