In normal Python code, if you have a class that subclasses from multiple
parents and you try to access an attribute on a parent, Python just
picks the first occurrence as it walks through the MRO (method
resolution order) list.
In ModelForms, if you specify the Meta inner class on multiple parents
(and not on the child class), we walk through all the parents in __new__
to check that each Meta is consistent. But we still only use the one of
them (fortunately). All this extra walking and error checking leads to a
bunch of extra code that isn't totally trivial. I'd like to remove it
(it's a dozen lines of code that keeps finding its way into problem
reports).
If people specify multiple Meta classes on parents, we're only going to
use the first one -- just like Python always does. If they want to
adjust the parent's Meta class, they can subclass in their child class,
just like Python always allows and encourages. We don't appear to be
trying to do anything funky by taking pieces out of the parent's Meta
when Meta is specified in the child and doesn't subclass the parent's
Meta. So this isn't removing functionality. It's just removing a
paranoia check that would only be triggered if you suddenly expected
Python to behave differently than it normally did. (Plus the number of
people doing multiple inheritance there is likely to be tiny. The only
real utility is for mix-in adding of methods.)
Any strong objections to not behaving like Python here?
Malcolm
--
Depression is merely anger without enthusiasm.
http://www.pointy-stick.com/blog/
Oh, bother. Darn double-negatives. Remove the 'not'. Sentence makes more
sense, then.
Malcolm
--
Honk if you love peace and quiet.
http://www.pointy-stick.com/blog/
The less magic the better.
--
Patryk Zawadzki
PLD Linux Distribution
Sounds like it's well worth removing. +1.
Adrian
--
Adrian Holovaty
holovaty.com | djangoproject.com
No. Please make the change. I was looking at this the other day and
had one of those "did I really write this?" moments. Thank you for
taking care of #6337 [1] too. That should make it a lot easier for me
to get rid of my last nit with #6241.
Joseph
[1] http://code.djangoproject.com/ticket/6337
[2] http://code.djangoproject.com/ticket/6241
Well, let's not overrate the importance of this. That particular code
would only have been visible if you did something dumb. It wasn't going
to mislead people. But it will be used so infrequently and adds a fair
bit of clutter (and processing).
Anyway, decision made now. Both Adrian and Joseph are happy with the
change. Thanks for the rapid feedback, guys.
Regards,
Malcolm
--
The early bird may get the worm, but the second mouse gets the cheese.
http://www.pointy-stick.com/blog/