Dawned on me that the Django auth user model that ships with Django is like the string built-in of a high level programming language. With the string built-in it's oh so tempting to add custom functionality to it like a fancy captialization method or some other function that automatically strips whitespace or what not. Yes, I'm looking at you Prototype for example.
By NOT doing that, and leaving it as it is, you automatically manage to Keep It Simple Stupid and your application code makes sense to the next developer who joins your project.
I'm not a smart programmer but I'm a smart developer in that I'm good at keeping things pure and simple. It means I can't show off any fancy generators, monads or metaclasses but it does mean that fellow coders who follow my steps can more quickly hit the ground running.
My colleagues and I now have more than ten Django projects that rely on, without overriding, the django.contrib.auth.models.User class and there has been many times where I've been tempted to use it as a base class or something instead but in retrospect I'm wholeheartedly happy I didn't. The benefit isn't technical; it's a matter of teamwork and holistic productivity.
Comments
Post your own commentHave you ever extended the User object in another way, then? Without using subclasses? How did you do it? Did you make another model with a ForeignKey to User?
Or did you use User profiles?
Cheers,
Vincent
Yes, User profiles all the way!
+1 to user profiles!
Instead of sub-classing, you can look at using mix-ins.
How is that any different? My point was that by leaving it as it is it becomes predictable when you go from project to project.
Perfect! Googled for this problem and I get your blog of all things. I was trying to access a user's profile photo in a comments template - the photo is stored in a custom model which references contrib.auth.models.User, and I had the option of doing something crazy with users, or adding 1 line of code. User Profiles is perfect.