Re: is_valid as property

[Sjoerd Job Postmus]

Replacing functions with properties will create a lot of churn in the people using the mentioned functions.

Another approach might be to wrap these functions in a class with `__call__` and `__bool__` both calling the underlying function. Or `__bool__` raising an error? [1]

I myself am a fan of errors here.

[1] and __nonzero__.

On Sep 29, 2016 7:57 PM, "Sven R. Kunze" <srku...@gmail.com> wrote:

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+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/e36d0f0a-fee8-4340-9d8a-24402dd55b76%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/ab53d585-7ac4-4c68-bdb3-ec4c41f6e6e6%40email.android.com.
For more options, visit https://groups.google.com/d/optout.