On Tue, Sep 10, 2013 at 7:34 AM, Marc Tamlyn <marc.tam...@gmail.com> wrote:
> I'm not sure either way on this one. I don't want people to get carries > away with Meta, it's not a dumping ground for any old thing you like. That > said, for a developer of a third party library which extends the ORM, the > inability to extend Meta is very problematic. > > I think a balance could be found where strict validation is retained, but > third party apps can add to that validation. The difficulty is the API - if > would be good if it could be done on a per model basis rather than a > global. This should be explicit on behalf of the end user. I'm not sure how > this would work though. > On the basis that this discussion is happening at all, I've just closed #21081 as a duplicate of a newly-reopened #5793. I share James' reservations about this as a feature -- attaching flags to Meta is something I can see being abused in all sorts of ways -- but that doesn't mean there's no legitimate uses for extensions to Meta. For example, the USERNAME_FIELD added in support of custom users should, arguably, be a Meta option -- but there was no way we could add that without making a Meta option available to every class. So - I think custom Meta options are something that should be *possible*. I don't have any particular ideas for how it should be implemented, though. 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 django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. For more options, visit https://groups.google.com/groups/opt_out.
