__init__ should be kwargs-only

[wsanchez]

The initializer should ideally be kwargs-only. That is:

	def __init__(self, name: str, …

should be:

	def __init__(self, *, name: str, …

The reason is that the automatically generated methods are all using the definition order in the class, so if, for example, I add a new attribute and I want comparison to look at it before some other attribute, I’d have to possibly change the definition order, which will change the signature of init in an incompatible way. By making the method kwargs-only, you can ensure that you aren't breaking clients when you do that.

[wsanchez]

Related in attrs: python-attrs/attrs#106

[gvanrossum]

I disagree. If I have a Point class with attributes x, y and z I'd like to be able to call Point(0.1, 3.14, 42) rather than having to specify Point(x=0.1, y=3.14, z=42).

[wsanchez]

OK, I see the cosmetic win there, but what if you started without y and then want to add it, and it really belongs in the middle for __lt__ and the like?

Perhaps a means to specify the comparison order for attributes, then.

The problem here is we're coupling definition order to a few things that aren't necessarily otherwise coupled to each other.

[ilevkivskyi]

I am with Guido here. Requiring kwargs-only by default is too radical. I could imagine an option in @dataclass decorator, but even this is questionable.

[ericvsmith]

I think we don't want to support keyword-only params to __init__(). As @wsanchez notes, the same problem exists with comparison operators. I think we should just live with definition-order for initialization and for comparisons. If you want something more, specify your own __init__() or comparisons, and use the generated functions that are of value to you.