Hello again! > What you have suggested here **is** an invasive change, because it > requires changes to existing code paths.
I think the way to measure "invasive" is by means of backwards compatibility. We do not change required arguments, return value or model fields... The view normally responds with an HttpResponseRedirect object, and that's also the case here. > A setting is not a good way to > make something configurable here. A keyword argument here *would* be an > acceptable solution. You're right. Keywords argument is a good idea! > However, I don't think it would be that useful, because if it was off by > default, and controlled by a keyword argument, then the admin login view > wouldn't use it. I think this needs more thought. True! Actually this speaks against the use of a keyword argument as sole option. Keyword option: Local per-view behavior Setting variable: Project-wide behavior used when there is no kwarg present > Again, I should mention that features like this get implemented by the > community. If you need it, the way to do it is to build it, and then > persuade us to use it - not to try to persuade *us* to build it :-) I'm actually trying to persuade myself to build it in case there's enough support+discussion for it. > BTW - this doesn't actually force the password reset - it logs them in > and then asks them to change their password. If they don't they are > still logged in. Yup, that needs more thought! all the best, Benjamin -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
