Am Donnerstag, 29. September 2016 18:55:37 UTC+2 schrieb Tim Graham:
>
> #1. Regarding templates, one of the arguments for the previous change was:
>
> Django 1.8 worsens the situation significantly:
>
> {% if request.user.is_authenticated %}
>
> does the right thing in a Django template but is a security vulnerability
> in a Jinja2 template!
>
Ah, yes. I for one think that this is just a minor issue as changing the
underlying template engine is not done on a regular basis. But that might
just be me.
If it contributes as an argument, why not. I don't see anything wrong with
using is_valid/has_changed in templates especially when we need to display
field errors.
> #2. There was an inconsistency with the is_staff, is_active, is_superuser
> attributes and is_anonymous, is_authenticated as methods. I'm not sure what
> the inconsistency is with forms. Yes, there's an Form.is_bound property and
> an is_multipart() method but I don't see a need to convert all is_*()
> methods to properties.
>
>
> In my mind, the security ramifications were the main reason for the
> previous change, and I don't see those concerns here. Changing
> Form.is_valid() to a property seems like it would cause much more
> disruption across the Django ecosystem than the gain would be worth.
>
It's always the combination of several issues. Here are mine:
#1 Inconsistency
For newbies that's the hardest part; especially when now compared to
is_authenticated and other boolean attributes/properties even within Django.
#2 Wasted Effort
Also on a regular basis; which is quite problematic for commercial
projects. Focusing on the topic at hand is more important than such
technical details.
The mentioned dev who missed the "()" is one of our most experienced devs
and that mentioned piece of code is only 3 years old.
#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
#4 Django devs are not only Django devs
They are Python devs as well and usually Django as a single lib is not
enough. Especially Python devs expect things to work the same also across
most libs such as boolean attributes/properties.
You might not find them worth enough to warrant the trouble. I for one do,
hence the post. But it's not me to decide. :)
Some related thought: relating Django's past lifetime with its projected
future lifetime which still lies ahead, Django is still in its infancy.
So, I guess that any change no matter how "disruptive" for the sake of
consistency will eventually pay out. Latter generations will be grateful
not to distinguish between situations where they need "()" and where they
don't.
--
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/e36d0f0a-fee8-4340-9d8a-24402dd55b76%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
