attrs-decorated classes don't play nicely with sibling __init__ methods

[zenbot]

attrs-decorated classes can produce unexpected behaviour when they exist in an inheritance tree with non-attrs-decorated classes that define their own __init__ methods, because those __init__ methods aren't called. This dumb test exercises this:

def test_init_with_multiple_inheritance():
    import attr

    @attr.s
    class A(object):
        a = attr.ib(default=42)

    class B(object):
        def __init__(self):
            super(B, self).__init__()
            self.b = 3

    class C(A, B):
        pass

    c = C()
    assert c.a == 42
    assert c.b == 3

The second assertion currently fails with an AttributeError.

In ordinary Python code this would be addressed with a super call in A.__init__, but I'm not sure if adding a super to the __init__ returned from _attrs_to_script would achieve the same result without breaking a bunch of other cases.

(I apologise for not digging further & submitting a patch; the code in _make.py is a little too terrifying to get stuck into a Monday morning!)

[hynek]

The problem is, that attrs has no way to know, how to call super (i.e. with what arguments).

I believe this could be solved by the suggested solutions to #25 (IOW: support for a custom __init__ hook)?

Until then you'll have to write your own __init__ sadly.

[Insoleet]

I have a suggestion : use something like PyQt5 does ( http://pyqt.sourceforge.net/Docs/PyQt5/multiinheritance.html )

For example, the following code :

    @attr.s
    class A(object):
        a = attr.ib(default=42)

would generate something like this :

class A():
    def __init__(self, a=42, **kwds):
        super().__init__(**kwds)

        self.a = a

This way we could pass arguments to the super().__init__() method and safely call it using named parameters.

What do you think about it ? Are there any case which would not be covered by this behavior ?

EDIT : Here is a simple implementation which works fine for my case :

# the method is called by passing the cl.__base__ as the base parameter
def _attrs_to_script(attrs, base):
    """
    Return a valid Python script of an initializer for *attrs*.
    """

    # current code generating args does not change
    # [...]
    # I append the following :
    if base is not object:
        args.append("**kwargs")
        supercall = """
    frommodule = __import__('{module}', fromlist=[' '])
    supclass = getattr(frommodule, '{base}')
    super(supclass, self).__init__(**kwargs)""".format(base=base.__name__,
                                                           module=base.__module__)
    else:
        supercall = ""

    return """\
def __init__(self, {args}):
{supercall}
    {setters}
""".format(
        args=", ".join(args),
        supercall=supercall,
        setters="\n    ".join(lines) if lines else "pass",
    )

This works fine with a class such as the following :

from PyQt5.QtCore import QObject


@attr.s
class Foo(QObject):

    a = attr.ib()
    b = attr.ib()
    c = attr.ib()

Calling the constructor like this : foo = Foo(1, 2, 3, parent=None)
QObject.super(parent) is correctly called with None as a value.

I needed to import QObject in the generated script code because if I don't, I would get a NameError : name QObject not found. The empty fromlist is because of the following fact : http://stackoverflow.com/questions/2724260/why-does-pythons-import-require-fromlist

[hynek]

Honestly this looks like something with many edge cases and I explicitly do not want to have **kwargs in my __init__s because attrs is all about explicit APIs and zero-cost code generation. This approach adds quite a bit of runtime complexity whenever someone uses subclassing and muddles up the signatures of initializers..

I feel like this might be a great case for writing an attrs extension like @super_init that will implement exactly what you’re describing. attrs was always conceptualized for extensibility because of cases like this.

Another alternative might be once the aforementioned post-init-hook lands (hopefully 16.1) to add an explicit allow_kwargs option that lets you do your thing in __post_init__.

[Insoleet]

No problem, it was mostly a proof-of-concept to see what you would think about it. I understand your reasoning.
I'll try to realize an extension based on this concept. I'll need to modify the generated __init__ method. Is there any recommended way to do it ?

[hynek]

Not yet! If someone gives me a strong case + sane API I won’t regret in the future, I may make some innards public. But at this point you can only use the internal functions and play around with strings. And those can change quite radically, as seen in #60.

That’s why I suspect a hook-based system is better for everyone involved.

[hynek]

I believe this is fixed by __attrs_post_init__! Closing for now but please let me know if there’s anything broken.