Does the MRO matter when using declarative with mixins?

36 views
Skip to first unread message

Russ

unread,
Oct 17, 2011, 11:38:00 AM10/17/11
to sqlal...@googlegroups.com
All the declarative examples have DeclarativeBase as the first/left base class.  Does it need to be?  I've swapped it in several code locations and experimented and it seems to be fine, but there's a lot going on with declarative and I'm vaguely paranoid about messing it up subtly by altering the MRO.

ie: This is "normal", and is how all declarative examples are done:

class Foo(Base, MyMixin):
    #snip

but is this also ok, or will it cause issues somehow?

class Foo2(MyMixin, Base):
    #snip

The reason I'm looking at this is that I've got a case with multiple mixin classes, and when the "top" mixin used doesn't have an __init__ definition, but a lower level class does, having the declarative base first fails because it doesn't use a (*args, **kwargs) catchall.  I also wonder how super() will end up working out.

Since that last bit probably wasn't very clear, here is a small but full example of what I mean:

Resolving the __init__ args issue is resolved by putting the Mixin first.  I just want to make sure it is fine.

Michael Bayer

unread,
Oct 17, 2011, 12:27:51 PM10/17/11
to sqlal...@googlegroups.com
On Oct 17, 2011, at 11:38 AM, Russ wrote:

All the declarative examples have DeclarativeBase as the first/left base class.  Does it need to be?  I've swapped it in several code locations and experimented and it seems to be fine, but there's a lot going on with declarative and I'm vaguely paranoid about messing it up subtly by altering the MRO.

ie: This is "normal", and is how all declarative examples are done:

class Foo(Base, MyMixin):
    #snip

but is this also ok, or will it cause issues somehow?

class Foo2(MyMixin, Base):
    #snip

The MRO basically matters as much as it matters in any case.   If your mixin has an attribute that's not in a prior class within the MRO, that's the attribute that wins.   Declarative scans through the whole MRO at startup but pretty much keeps things the way they work anyway (deviations from that would be bugs).

Actually I usually put the mixins first, because you're overriding whatever is the "base".  I should even change the docs in that regard, it's weird that they don't use that convention.   Looking now it's actually fairly awkward the way it is.

Russ

unread,
Oct 17, 2011, 12:39:04 PM10/17/11
to sqlal...@googlegroups.com
Great - thanks for the response.   This was causing me more brain ache than I care to admit.  My paranoia was rooted in the fact that the docs did seem to go out of their way to put the Base first (without specifically saying so) which is awkward as you say.

Much appreciated.
Reply all
Reply to author
Forward
0 new messages