Hi all,
I've now addressed everything in Russell's last e-mail, I think, so I
think I'm pretty much good to go, apart from:
1) my last change rewrote a lot of IfParser, which was the heart of
the patch. That means it probably needs looking at again! On the other
hand, the new implementation is based on a much more general and more
tested parser methodology, so it should hopefully be pretty solid.
2) what should be done about errors with operators? For the most
part, it isn't much of an issue, as 'object' defines many of the magic
methods involved. For 'in', however, you are likely to get TypeErrors
if the object doesn't support it. Currently missing variables are
handled gracefully, but {% if 'x' in 1 %} will get you a TypeError
that is not caught. And there is still the possibility that other
operators will cause errors.
Our current policies don't quite handle this situation, AFAICS. For
the case of 'in', catching any Exception and returning False could be
defended - to use the above example, 1 is not an object that contains
'x', therefore it should return False. This would protect template
authors against various exceptions.
Or we could go with the policy for method calls, which is to check the
exception for 'silent_variable_failure' attribute. This has the
advantage that inappropriate use of 'in' by template authors, which is
almost always going to be a mistake, will throw a loud error. The
error message in this case isn't particularly obvious though:
"TypeError: argument of type 'int' is not iterable"
I'm leaning towards the latter. If a view changes so that, in the
variables passed to the template, a container with a __contains__()
method is replaced by one without, or by one with a buggy
__contains__() method that throws exceptions, it's more useful and
arguably more correct to get an exception than for the 'if' tag
expression to return False.
Regards,
Luke
--
"If something is hard, it's not worth doing." (Homer Simpson)
Luke Plant || http://lukeplant.me.uk/
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
