> Mainly, I just don't think you're subclassing User for the right > reasons. In fact, I can't really think of anytime I would subclass > it. Usually adding a related table is a better way to go (lookup > django user profiles for example). >
There are times when the builtin User model is not enough, that's why there is a way to specify user profiles. There are times when you want to be sure that every user in the system has a profile (some filed in the profile is required for the system to work properly), even for the users added from the admin. This can lead people to try all kinds of hacks, like subclassing user, which there is a way to implement but will lead you in all kinds of trouble. Then there is the case where you want all users to be staff no matter what, which makes the field superficial, but leads to extra uneccessary work on the developers part to make sure it works that way. These are all real world scenarios I've encountered, and I'm guilty of pushing a subclassed user model in the past. If the api leads a lot of people to try all kinds of hacks around it to achieve what they want, blame the API not the people. Providing concrete models for users in contrib leads to more pain than the time or trouble it saves. -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
