I'd want to know of a solid use case for that extra flag -- IOW KISS. When would you want to have a positional argument to __init__ not be allowable as a positional pattern argument, or vice versa? AFAIK there isn't even a way to indicate that an init field should always be passed as a keyword argument. (But I'm personally a very unsophisticated user of dataclasses, and it's been ages since I read the PEP.)

To show how it works using both dataclasses and regular classes you could leave BinaryOp a regular class but turn UnaryOp and VarExpr into dataclasses. BinaryOp has a precedence attribute that's not a parameter, so you'd have to define a __post_init__ method, and at that point it's hardly a win.

Well, it's a two-way door in any case, we can always add it later if someone decides they need it. I'm fine with leaving things as-is.

Do we have any plans for __match_args_required__ for dataclasses?

I propose to leave that unset. Users wishing that feature can set it.

The PEP says we set it. So either we should set it, or change the PEP!

So set it if not already set. To 0, I suppose. What difference does make though?

For dataclasses the __match_args_required__ includes all fields without a default value, or a default factory.

I privately worry that will constrain us. While 'Point(0)' seems perhaps an odd shortcut for 'Point(0, _)', I am not so sure that we want to disallow 'Point(x=0)'.

Well, we could just strike the line from the PEP. Like you said, anyone who wants to require args can set __match_args_required__ on the class manually.

I could go either way, honestly. The deconstruction signature will never be perfectly compatible with the constructor signature, but it does seem that we haven't found a real-world use-case where we're willing to set __match_args_required__... I mean, the PEP uses your exact example of a Point class to sell the feature.

So either we should choose to set it for named tuples and dataclasses, find a more compelling example for the PEP, or consider dropping it from the spec.

What do others think? @Tobias-Kohn ?

I'm slightly in favor of killing it off. Looking it up and validating it takes time and effort, and we haven't really found any good use cases.

Since we probably wouldn't add it to any built-in types, we could always add it back later with minimal disruption.

Plus, I think it currently holds the world record for "most ridiculously long dunder".

For some background, here's the comment that first suggested it:

#19 (comment)

Later, @ilevkivskyi said:

Anyway, you at least convinced me that your approach is extensible in the direction I want (i.e. __required_match_args__ can be added later without breaking backwards compatibility).

So you propose to kill it completely? That sounds fine to me, we can add it to Rejected (or Postponed) ideas.

I am also at most lukewarm towards the __match_args_required__ and am absolutely happy to remove it. @brandtbucher makes a couple of very good points, particularly that we only have a single use case so far.