On Sep 20, 2013, at 10:58 AM, [email protected] wrote:

> > No other User model needs to [set swappable]
> 
> This would still be the case. Only models that want to conditionally load 
> themselves would set swappable. User models in application code probably 
> wouldn't set it, because the project will always use that one user model.

This is my understanding too. If you set a user model in individual project 
code, there's no point in defining it as swappable, as that project is always 
going to want to use it.

If you're writing the authtools app, you probably do want to define the user 
model or models you offer as swappable, but that seems like it's still true now.

> > ... made a special case of "Swappable models in the same app".
> 
> I'm not sure where there's a special case. Swappable works for this without 
> any modifications, see authtools.
> 
> > *Any* model can be swapped in as a substitute user. 
> 
> Yep. Nothing needs to change to keep this possible.
> 
> > If we were to go down this path, the logical extension (to my mind) would 
> > be to validate that you're not swapping in a model that hasn't declared 
> > itself as swappable
> 
> Why would you want to validate this? Swappable only controls loading of the 
> model its set on, there is no action-at-a-distance on other models.

I, too, don't really understand this assumption. The status quo works just 
fine, and makes complete sense to me.

> I don't think we should focus so much on the optional part of the proposal. 
> The really important part is to refactor the existing code to work better 
> with custom users. Once this happens, projects like authtools can trivially 
> add an EmailUser in a few lines of code, so it's not so important that 
> there's one in core.

Eh, I pretty passionately believe that this particular use case needs to be in 
core. It's **really** common. But, the point that you make is why I am 
passionate about not just making an auth_email app, because I see the other 
approach as *also* having more value in simplifying some other more-simple user 
substitutes.

L

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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.
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to