[issue32513] dataclasses: make it easier to use user-supplied special methods

Change by Karthikeyan Singaravelan : -- pull_requests: +9702 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue32513] dataclasses: make it easier to use user-supplied special methods

Change by Karthikeyan Singaravelan : -- pull_requests: -9682 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue32513] dataclasses: make it easier to use user-supplied special methods

Change by Karthikeyan Singaravelan : -- pull_requests: +9682 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue32513] dataclasses: make it easier to use user-supplied special methods

Guido van Rossum added the comment: Nit: I think the presentation of the 12-row table in msg310830 can be improved, e.g. by putting the legend for add* closer and/or giving add* a clearer name, and by splitting it into three 4-row tables. Currently the legend comes before

[issue32513] dataclasses: make it easier to use user-supplied special methods

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

[issue32513] dataclasses: make it easier to use user-supplied special methods

Eric V. Smith added the comment: New changeset ea8fc52e75363276db23c6a8d7a689f79efce4f9 by Eric V. Smith in branch 'master': bpo-32513: Make it easier to override dunders in dataclasses. (GH-5366)

[issue32513] dataclasses: make it easier to use user-supplied special methods

Change by Eric V. Smith : -- keywords: +patch pull_requests: +5209 ___ Python tracker ___

[issue32513] dataclasses: make it easier to use user-supplied special methods

Eric V. Smith added the comment: I'm completely burned out on it, too. I'll get the code checked in today, then update the PEP later. I don't really want to add all of this reasoning to the PEP, but I guess I should. I think the gist of it is correct, in any event. We can

[issue32513] dataclasses: make it easier to use user-supplied special methods

Guido van Rossum added the comment: If Nick says it's okay it is okay. I think it's okay too but my brain doesn't want to start up today -- I suggest not waiting for me. -- ___ Python tracker

[issue32513] dataclasses: make it easier to use user-supplied special methods

Nick Coghlan added the comment: Eric's current proposal sounds sensible to me, but I'll note that if we deem it necessary, the code that implicitly sets `__hash__ = None` to override object.__hash__ when __eq__ is defined could also set some other marker to make it more

[issue32513] dataclasses: make it easier to use user-supplied special methods

Eric V. Smith added the comment: I apologize for the length of this, but I want to be as precise as possible. I've no doubt made some mistakes, so corrections and discussion are welcomed. I'm adding the commented text at the end of this message to dataclasses.py. I'm

[issue32513] dataclasses: make it easier to use user-supplied special methods

Guido van Rossum added the comment: Can you also clarify that this *never* looks at whether the method is implemented in a superclass? And clarify what happens with the __hash__ = None that's automatically created when you define __eq__. Please also repeat the default value

[issue32513] dataclasses: make it easier to use user-supplied special methods

Eric V. Smith added the comment: I'm working on a better formulation of the __hash__ issue, so don't invest much time in this until I post my next message. I'm going to re-organize the various tables to make them easier to read. --

[issue32513] dataclasses: make it easier to use user-supplied special methods

Eric V. Smith added the comment: Here's where I am on what methods are added under which circumstances. Hopefully these tables don't get mangled. The more I think about what to do with hash and raising exceptions, the more I think that the right answer is to not raise any

[issue32513] dataclasses: make it easier to use user-supplied special methods

Eric V. Smith added the comment: I'll look at the hash question later today. It's sufficiently complex that I really want to sit down and work through all of the cases. -- ___ Python tracker

[issue32513] dataclasses: make it easier to use user-supplied special methods

Guido van Rossum added the comment: Raising for order=True if one of the ordering dunders exists sounds fine. I am confused by the corner case for hash. Your table: """ eq=?frozen=?__hash__ False False do not generate __hash__ False True

[issue32513] dataclasses: make it easier to use user-supplied special methods

Eric V. Smith added the comment: I'm working on a patch before beta 1. The only issue is whether to raise in the case that order=True and the user specifies one of the 4 ordering dunders. I think raising is okay, especially since order=False is the default: you'd have to

[issue32513] dataclasses: make it easier to use user-supplied special methods

Guido van Rossum added the comment: Are we clear on the proposal now? It would be good to have this implemented in beta 1. Eric's long message looks good to me (though I have to admit the logic around __hash__ confuses me, but I've spent two long days at PyCascades, and I

[issue32513] dataclasses: make it easier to use user-supplied special methods

Nick Coghlan added the comment: I'd be fine with that recommendation (since `@dataclass(order=False)` and `@total_ordering` will compose without any problems), but in that case I'd suggest having "order=True" + any of the ordering methods result in an exception (as you've

[issue32513] dataclasses: make it easier to use user-supplied special methods

Eric V. Smith added the comment: Rather than re-implementing (and maintaining) functools.total_ordering semantics, I'd rather advise them to specify order=False and just use functools.total_ordering. It's an odd use case for dataclasses, anyway. --

[issue32513] dataclasses: make it easier to use user-supplied special methods

Nick Coghlan added the comment: For the ordering operators, my only question would be whether or not I can rely on them to act like functools.total_ordering: if I supply __eq__ and one of the ordering operators (e.g. __lt__), will dataclasses make sure the other three

[issue32513] dataclasses: make it easier to use user-supplied special methods

Eric V. Smith added the comment: The discussion on python-dev was that your ??? box would be "no": if the user supplied __repr__, they obviously meant for dataclass() to not provide one. I can't see why the user would say repr=True ("I want dataclass() to add __repr__"),

[issue32513] dataclasses: make it easier to use user-supplied special methods

Larry Hastings added the comment: So if I understand correctly: the default value of the "repr" parameter is True. Decision matrix: does dataclass insert a __repr__ into the class? +-- row: argument passed in to decorator's repr parameter | | v| yes | no

[issue32513] dataclasses: make it easier to use user-supplied special methods

Eric V. Smith added the comment: Oops, that should have been: if init is MISSING: init = True -- ___ Python tracker ___

[issue32513] dataclasses: make it easier to use user-supplied special methods

Eric V. Smith added the comment: Only hash has the tri-state True/False/None behavior, defaulting to None. It's this way because None is the "do what's rational, based on eq and frozen" behavior. None of the other parameters work this way. There's a long issue in the

[issue32513] dataclasses: make it easier to use user-supplied special methods

Larry Hastings added the comment: Do all the parameters to the decorator take a default value of "None", so that you can differentiate between explicit True, explicit False, and did-not-specify? Is this the complete list of these dunder-method-generation-control

[issue32513] dataclasses: make it easier to use user-supplied special methods

Eric V. Smith added the comment: Here is my proposal for making it easier for the user to supply dunder methods that dataclasses would otherwise automatically add to the class. For all of these cases, when I talk about init=, repr=, eq=, order=, hash=, or frozen=, I'm

[issue32513] dataclasses: make it easier to use user-supplied special methods

Change by Raymond Hettinger : -- keywords: +patch pull_requests: +5108 stage: -> patch review ___ Python tracker ___

[issue32513] dataclasses: make it easier to use user-supplied special methods

Eric V. Smith added the comment: See #32546 for the hash=None problem. -- ___ Python tracker ___

[issue32513] dataclasses: make it easier to use user-supplied special methods

Eric V. Smith added the comment: Another case to consider is that if a class defines __eq__, Python will automatically set hash=False before the decorator gets involved. NOte to self: be sure to add a test case for this. -- ___

[issue32513] dataclasses: make it easier to use user-supplied special methods

Change by Ivan Levkivskyi : -- nosy: +levkivskyi ___ Python tracker ___ ___

[issue32513] dataclasses: make it easier to use user-supplied special methods

New submission from Eric V. Smith : Modify dataclasses to make it easier to specify special methods. For example: currently, if you want to override __repr__, you need to specify @dataclass(repr=False), and also provide your own __repr__. Also, it's current an error to not