Hi Jonas -- On Mon, Aug 17, 2009 at 7:43 AM, Jonas Obrist<ojiido...@gmail.com> wrote: > Basically it lets you define a class in settings which extends the User > table before it's created, using subclassing.
This is a non-starter. It's not going to happen. Back in the day, Django actually had this "feature." There was a Meta option called "replaces_module" which did this: it reached in and replaced another model with the one you provided. If you do some googling for "replaces_module" you'll see it described as "hacky," "broken," "incredibly ugly," and other such complimentary terns. That's because while the *idea* of reaching in and replacing another model *sounds* like a good extension hook, in practice, it's nearly a cardinal sin. It means that if you make a change to the overridden model, that change doesn't show up -- because it's been overridden. It means that simply reading the model code isn't enough -- because something, somewhere, "might" replace it. Worse, it completely breaks the idea of a common utility module. If your app defines a user replacement, and my app defines a different one... we can't share code any more. Django's raison d'être is to facilitate application reuse; monkeypatching of any sort greatly hampers that. I appreciate that the user class isn't appropriate for everyone. But monkeypatching it isn't the solution. Jacob --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
