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 confusing if used with ""is False"""	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() }}} so is not False under any circumstances.

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 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	0	0