Hi Tim, On 01/04/2017 03:39 PM, Tim Martin wrote: > I've been looking at bug #24977 (Template variables with a value of > None are considered to be == to non-existent properties). ... > The suggestion on the ticket is to use an instance of a special > `Undefined` class to indicate an undefined variable, which could never > compare equal to anything else. > > This sounds sensible, but in implementing it I got to thinking about > whether this can generalise and simplify. It seems like it might be > possible to combine both Engine.string_if_invalid and the > ignore_failures parameter to FilterExpression.resolve: > > * The Undefined object can have a __str__() that returns the > string_if_invalid value, so it acts like a string for the purposes > of rendering. > > * Returning the Undefined value is also sufficient to provide the > behaviour we need in the ignore_failures case: the calling code can > check for Undefined in the same case where it currently checks for > None. > > Overall the code is simpler, because a bunch of code paths are > eliminated.
Sounds great!
> However, there are 2 issues:
>
> 1) There are test cases where we have templates that should treat "x
> is y" as True where x and y are both undefined.
Really? Is this an accidental side effect of some historical change, or
really the intent of the test? That behavior seems buggy to me; more
likely to be a bug-magnet than useful.
...
> I don't see any way to satisfy both these requirements. Is it
> reasonable to relax the requirement that "x is y" should be treated
> as True when both variables are undefined?
Seems reasonable to me.
> 2) There appears to be an inconsistency in the default_if_none
> modifier. If I have a template with
>
> x|default_if_none:y = {{x|default_if_none:y}}
> {% if x|default_if_none:y %}
> x|default_if_none:y is apparently True
> {% endif %}
>
> with y defined to True and x undefined, then it produces:
>
> x|default_if_none:y =
> x|default_if_none:y is apparently True
>
> IOW it appears that the default_if_none doesn't cause y's value to
> be used in the case where the variable is being printed, even
> though it causes the expression to have y's value when evaluated in
> an if. I think this is something to do with the fact that the two
> ways of handling failures (ignore_failures and string_if_invalid)
> do different things.
>
> I don't see a way to make backward compatible code here.
>
> I think this is just a bug, does anyone think otherwise?
I agree.
Carl
--
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/14c76486-2649-c68f-a463-b5acf41b9556%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.
signature.asc
Description: OpenPGP digital signature
