[issue43764] Turning off generation of __match_args__ for dataclasses

Change by Eric V. Smith : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue43764] Turning off generation of __match_args__ for dataclasses

Eric V. Smith added the comment: New changeset 750f484752763fe9ac1d6455780aabcb67f25508 by Eric V. Smith in branch 'master': bpo-43764: Add match_args=False parameter to dataclass decorator and to make_dataclasses function. (GH-25337)

[issue43764] Turning off generation of __match_args__ for dataclasses

Change by Eric V. Smith : -- keywords: +patch pull_requests: +24072 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/25337 ___ Python tracker

[issue43764] Turning off generation of __match_args__ for dataclasses

Guido van Rossum added the comment: LGTM -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue43764] Turning off generation of __match_args__ for dataclasses

Eric V. Smith added the comment: I can go either way. It's easy enough for the user to add their own __match_args__, so I won't link them. Here's what I have for the documentation, which is why the issue came up: - ``match_args``: If true (the default is ``True``), the

[issue43764] Turning off generation of __match_args__ for dataclasses

Guido van Rossum added the comment: There may be other reasons why `__init__` is not desired, and there's no absolute requirement that `__match_args__` must match the constructor -- only a convention. I'd say don't tie them together. -- ___ Python

[issue43764] Turning off generation of __match_args__ for dataclasses

Eric V. Smith added the comment: > Are there other cases where suppressing one thing affects others? Only the complex interactions among the unsafe_hash, eq, and frozen parameters. It feels like if __init__ is not being generated, then the @dataclass code would have no idea what it should

[issue43764] Turning off generation of __match_args__ for dataclasses

Guido van Rossum added the comment: Are there other cases where suppressing one thing affects others? -- ___ Python tracker ___

[issue43764] Turning off generation of __match_args__ for dataclasses

Eric V. Smith added the comment: Here's a question. If __init__ is not being generated, either because the user supplied one to this class, or if init=False is specified, should __match_args__ be generated? I think the answer should be no, since the code has no idea what the parameters to

[issue43764] Turning off generation of __match_args__ for dataclasses

Eric V. Smith added the comment: Okay, I'll re-open this to just add @dataclass(match_args=False). -- resolution: rejected -> stage: resolved -> needs patch status: closed -> open ___ Python tracker

[issue43764] Turning off generation of __match_args__ for dataclasses

Guido van Rossum added the comment: I don't think we need control at the field level here. Omitting one field is just going to cause confusion. -- ___ Python tracker ___

[issue43764] Turning off generation of __match_args__ for dataclasses

Eric V. Smith added the comment: > So, should we reopen this ad add the flag to suppress __match_args__ > generation after all? I think so, although I'm still contemplating it. I can't decide if we should also add match_arg=False to field(). Or is it good enough to just tell the user to

[issue43764] Turning off generation of __match_args__ for dataclasses

Guido van Rossum added the comment: So, should we reopen this ad add the flag to suppress __match_args__ generation after all? -- ___ Python tracker ___

[issue43764] Turning off generation of __match_args__ for dataclasses

Eric V. Smith added the comment: Hmm, good point on the inheritance case. I'd forgotten that this is where init=False and others would come in handy. Although I'm having a hard time figuring out why you'd want a derived class that adds fields but wants to use the parent's __match_args__ (or

[issue43764] Turning off generation of __match_args__ for dataclasses

Brandt Bucher added the comment: I just realized that in my first two examples, all that's really needed is a "del Child.__match_args__" following each class definition. The main point still stands though: this may be a more common issue than I previously thought. If it is, then a dedicated

[issue43764] Turning off generation of __match_args__ for dataclasses

Brandt Bucher added the comment: > init=False is used to make sure there's no __init__ defined, because there's > a difference between a class with an __init__ and one without. If there was a > difference between __match_args__ being not present and __match_args__=(), > then I'd support a

[issue43764] Turning off generation of __match_args__ for dataclasses

Eric V. Smith added the comment: init=False is used to make sure there's no __init__ defined, because there's a difference between a class with an __init__ and one without. If there was a difference between __match_args__ being not present and __match_args__=(), then I'd support a

[issue43764] Turning off generation of __match_args__ for dataclasses

Adrian Freund added the comment: > I assume the OP wants to have a class that doesn't allow positional patterns. > The right way to spell that is indeed to add > >__match_args__ = () > >to the class, there's no need to add another flag to @dataclass. The same however is also true for all

[issue43764] Turning off generation of __match_args__ for dataclasses

Brandt Bucher added the comment: New changeset d92c59f48680122ce0e4d1ccf69d92b983e8db01 by Brandt Bucher in branch 'master': bpo-43764: Fix `__match_args__` generation logic for dataclasses (GH-25284) https://github.com/python/cpython/commit/d92c59f48680122ce0e4d1ccf69d92b983e8db01

[issue43764] Turning off generation of __match_args__ for dataclasses

Change by Brandt Bucher : -- pull_requests: +24020 pull_request: https://github.com/python/cpython/pull/25284 ___ Python tracker ___

[issue43764] Turning off generation of __match_args__ for dataclasses

Guido van Rossum added the comment: I assume the OP wants to have a class that doesn't allow positional patterns. The right way to spell that is indeed to add __match_args__ = () to the class, there's no need to add another flag to @dataclass. -- resolution: -> rejected stage:

[issue43764] Turning off generation of __match_args__ for dataclasses

Brandt Bucher added the comment: > Note that setting compare=False on a dataclass.field already excludes that > field from __match_args__... It appears you did find a genuine bug though! I was surprised by this comment, and after digging a bit deeper into _process_class found that we should

[issue43764] Turning off generation of __match_args__ for dataclasses

Brandt Bucher added the comment: I agree with Eric. You can already disable the automatic creation of __match_args__ by setting it yourself on the class being decorated, and "__match_args__ = ()" will make the class behave the exact same as if __match_args__ is not defined at all. >>> from

[issue43764] Turning off generation of __match_args__ for dataclasses

Eric V. Smith added the comment: What's the situation where having __match_args__ is actually harmful in some way? I understand that if the generated version is wrong, you'd want to specify it yourself. But what's the use case for not having __match_args__ at all? -- assignee: ->

[issue43764] Turning off generation of __match_args__ for dataclasses

New submission from Adrian Freund : The dataclass decorator can take multiple parameters to enable or disable the generation of certain methods. PEP 634 Structural Pattern Matching extends dataclasses to also generate a __match_args__ attribute. I think adding a parameter to enable and