attrs misconceptions

[hynek]

Hi,

I would like to correct some attrs misconceptions. :)

1. Custom __init__: you can always pass @attrs(init=False) and no __init__ is generated so that doesn’t seem like a fair criticism (basically: you have to pass an argument :))?
2. Subclassing: attrs has wonderful support for sub-classing; it just works a bit differently. From the examples page:

>>> @attr.s
... class A(object):
...     a = attr.ib()
...     def get_a(self):
...         return self.a
>>> @attr.s
... class B(object):
...     b = attr.ib()
>>> @attr.s
... class C(B, A):
...     c = attr.ib()
>>> i = C(1, 2, 3)
>>> i
C(a=1, b=2, c=3)
>>> i == C(1, 2, 3)
True
>>> i.get_a()
1

In other words: if you’re composing attrs classes, everything works out of the box as you’d wish to. If you’re mixing in 3rd party classes it’s more complicated and you’ll have to write your own __init__.

Cheers, —h

[ionelmc]

I've corrected some wording, see commit.

[hynek]

Thanks! I’ll be back once I’ve implemented @attr.s(post=True) (that calls a custom method after __init__ is done). :)

[ionelmc]

I can see how this is a clever ploy to change fields tag line to "Fields - a thing making the attrs library better" :-)

On Saturday, 13 August 2016, Hynek Schlawack notifications@github.com wrote:

Thanks! I’ll be back once I’ve implemented @attr.s(post=True) (that calls a custom method after init is done). :)

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/ionelmc/python-fields/issues/4#issuecomment-239611113, or mute the thread https://github.com/notifications/unsubscribe-auth/AAH53chEnU5cPZCqGMPuAX8JvkeuxWbEks5qfYiegaJpZM4JjoFn .

Thanks, -- Ionel Cristian Mărieș, http://blog.ionelmc.ro