id	summary	reporter	owner	description	type	status	component	version	severity	resolution	keywords	cc	stage	has_patch	needs_docs	needs_tests	needs_better_patch	easy	ui_ux
26988	User is_authenticated callable property is confusing to check	Mark Tranchant	nobody	"Just upgraded to 1.10, converted all {{{is_authenticated()}}} methods into {{{is_authenticated}}} properties as per the [https://docs.djangoproject.com/en/1.10/releases/1.10/#using-user-is-authenticated-and-user-is-anonymous-as-methods Release Notes] and a test in my test suite failed. 

It turns out I was checking for a logged in user with {{{if request.user.is_authenticated is False:}}}, but the {{{is_authenticated}}} property is actually a {{{CallableBool}}} which cannot be tested with {{== False}}, {{is False}}, {{== True}} or {{is True}}.

Checking this property only gives logical results with direct {{{if user.is_authenticated}}} or {{{if not user.is_authenticated}}}. This is very misleading and non-intuitive behaviour (at odds with [https://www.python.org/dev/peps/pep-0008/#programming-recommendations PEP8 (bottom of linked section)]) and should be fixed or strongly called out in the documentation. Example:

{{{
In [1]: from django.contrib.auth.models import AnonymousUser, AbstractBaseUser

In [2]: a = AnonymousUser()

In [3]: b = AbstractBaseUser()

In [4]: a.is_authenticated
Out[4]: CallableBool(False)

In [5]: b.is_authenticated
Out[5]: CallableBool(True)

In [6]: a.is_authenticated is False
Out[6]: False

In [7]: a.is_authenticated == False
Out[7]: False

In [8]: not a.is_authenticated
Out[8]: True

In [9]: not b.is_authenticated
Out[9]: False

In [10]: b.is_authenticated == False
Out[10]: False

In [11]: b.is_authenticated == True
Out[11]: False
}}}"	Uncategorized	new	contrib.auth	1.10	Release blocker		user is_authenticated property test		Unreviewed	0	0	0	0	1	0