Ok, I see where your suggestions could make a lot of sense. Thanks for persisting with me.
I've updated my gist again with what a refactor could allow it to look like: https://gist.github.com/jarshwah/c5b9abebb452f2e3286f The backend remains unchanged. The form removes most custom handling, assuming that it would call methods on the user which delegates to the backend (which then calls methods on the user again if the ModelBackend is in use). I keep my view as-is, but I could probably just use the contrib.auth.views.password_change view. So yes, I can see the value in what you're proposing. But I would have a few concerns. 1. You'd need to make sure that you don't break backwards-compatibility 2. You shouldn't introduce new settings unless there's an extremely good reason 3. The refactored methods should be general enough to work with the vast majority of custom backends I think you should put a patch together. It'll be easier to see the benefits when there is a working design to be reviewed. It's much easier to discuss an implementation rather than the idea for an implementation. Although if the idea is rejected, you should still be able to implement multiple backends in a relatively generic way, by dispatching based on the user.backend property. Josh -- 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/1b95d6eb-6c8c-4778-a89f-78073efb4c4d%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
