Firstly, I was attempting documenting the existing behaviour, nothing
more. I wasn't intending to document every single use of is_active
within Django; the idea was simply to indicate that it wasn't the same
as "can login" and I didn't want the documentation of the edge-cases
(every single use of the function) to overwhelm the substance of the
feature.
If I've missed a case where it is used on the login path or something,
please file a patch to amend that. Accurate documentation is a good
thing. Incorrect documentation is a bug.
With respect to changing the behaviour: we can't really change is_active
to mean cannot_login now, since that would not be backwards compatible
and would be hard to detect for existing sites. Something that
previously worked would stop working without any kind of error message.
So that's not really an option. Being allowed to login to do some
minimal thing (such as confirm an account) which then sets your account
to active isn't an inconceivable way of handling account registration or
re-activation.
Adding new things that depend on is_active is probably reasonable.
Whether sending password email is one of them is something I haven't
thought about yet (particularly as to how it ties into the "you have a
very restricted account until we make it active" style of use). But
making it equivalent to 'cannot login' is not something I'd be in favour
of.
Regards,
Malcolm