Hi Gavin, On Sat, Sep 21, 2013 at 12:58 AM, <[email protected]> wrote:
> > The intention was to mark a particular model as a something that can be > replaced. > > It's hard to find the original rationale behind swappable, but my mental > model was always: > > A model with `swappable = 'x'` means that the model should only be > loading if settings.x is set to that same model > Well, it's hard to find the rationale because it's an internal API that (like the rest of Meta) isn't documented. However, I can speak with authority on the original rationale, because I was the person who wrote the code, and I had a specific intention in mind :-) > it's still not desirable. > > Why not? Swappable seems like exactly what we need here. > > > 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. > > > ... 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. > This all hinges on the interpretation. My intention was *not* that swappable meant "This model might not be loaded". My intention *was* that swappable meant "This particular model is an extension point that might be replaced by a third party." As I've indicated elsewhere, the fact that the implementation happens to support the first interpretation is accident, not intention. > > *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. > > > Secondly, marking a model as swappable doesn't make it zero cost. > > That's fair. I'll add it to the wiki as a disadvantage. > And this remains my biggest reason why the first interpretation isn't the right interpretation. We shouldn't be encouraging people to build monolithic apps containing dozens of "swappable" models. We should be encouraging people to write small, tight apps that fill a single purpose. > > So far, the only convincing argument I've heard for putting the > EmailUser in contrib.auth is that it avoids having to add a value to > INSTALLED_APPS. > > 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. > I'm not sure exactly what you mean by the "optional" part of the proposal. Where the code will sit seems like a pretty important question to me. There are other questions to be resolved as well, but it seems to me that those discussions are currently being swamped. I may need to a reboot of this conversation. Yours, Russ Magee %-) -- 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.
