Thinking of an alternative route:
It seems to me that the default `method.__bool__` is undesirable in Jinja2 templates. I do not know Jinja2 well enough, but maybe they could benefit from a patch where `if`-statements give a warning/error when the _expression_ is a callable (with the default `FunctionType.__bool__`?
This would solve the issue not just for the methods you mention, but more in general.
[Or maybe Python itself should have that warning/error?]
Does that make sense?
On Sep 29, 2016 9:09 PM, "Sven R. Kunze" <srku...@gmail.com> wrote:
--Hi Aymeric,thanks for your ideas.Am Donnerstag, 29. September 2016 20:26:54 UTC+2 schrieb Aymeric Augustin:Hello,On 29 Sep 2016, at 19:57, Sven R. Kunze <srk...@gmail.com> wrote:#3 "Errors should never pass silently."Which they do if you write:if form.is_valid:# will always be executed# as it is always trueThis is perhaps the strongest argument in this discussion but I’m not convinced it’s strong enough to make the change.It’s weaker than the inconsistency that appeared between `{% if request.user.is_authenticated %}` in Django templates and `{% if request.user.is_ authenticated() %}` in Jinja2 templates when Django started supporting both natively. The root cause of that inconsistency was Django’s auto-calling of callable in templates. This factor doesn’t exist here. That could depend on the perspective which argument is stronger or weaker. But independently, I still miss the point why {% if form.is_valid %} cannot be a problem in Jinja2?Writing `if some_callable:` instead of `if some_callable()` will cause the issue described here for any callable whose result makes sense in a boolean context. It’s always possible to build a security vulnerabilities with this behavior, by putting something security sensitive in the `if` or `else` block.Given that virtually anything can be evaluated in a boolean context in Python and in other dynamic languages such as _javascript_, I don’t know how to draw a line between what should be a property and what should be a method. For example, I don’t think we want to make QuerySet.exists a magic CallableBoolean, do we?Now, that you mentioned it.... *seeking the "new topic" button* ;)Basically, the same arguments would apply there as well.Generally speaking, properties are expected to be cheap and methods can be expensive. In my opinion, for lack of a better guideline, we should stick to this one. `is_valid()` falls into the expensive category, and for this reason it should remain a method.Oh, I've never heard of this guideline. I just thought that properties should be used to reduce visual noise (such as parentheses and "get_" or "set_" prefixes.) or to replace a static attribute with a dynamic one. Cheap vs. expensive never played a role so far (at least where I worked). If that's relevant, we use "cached_property".Regards,Sven
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+unsubscribe@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/ecd30665-f698-4199-8fc3-d75ca66557d1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
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/88a914b2-13a0-40b8-bb42-20220977c13d%40email.android.com.
For more options, visit https://groups.google.com/d/optout.
