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 <javascript:>>
> 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 true
>
>
> This 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+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/ecd30665-f698-4199-8fc3-d75ca66557d1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
