This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author eric.smith
Recipients alan_du, eric.smith
Date 2018-05-16.08:26:24
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1526459184.99.0.682650639539.issue33129@psf.upfronthosting.co.za>
In-reply-to
Content
I'd forgotten about this issue and created #33493. I'll close it. Copied here is my comment from that issue:

I've had several requests for keyword-only arguments. This is a placeholder to remind me to work on it. I have not decided if it's a good idea or not.

I propose adding a keyword_only argument to field(), defaulting to False.

I'm thinking that the basic idea would be to put all keyword-only fields at the end of the arguments to __init__, but for all other uses, leave them where they appear in the class definition. That way comparison operations, in particular, would use the fields as they appear in the class definition (which is the current behavior). Since they'd be at the end of __init__, and since order doesn't matter (they're keyword-only, after all), then this would work as expected for base classes.

That is, given:

@dataclass
class B:
    a: field(type=int, keyword_only=True)
    b: int

@dataclass
class C(B):
    c: int
    d: field(type=int, keyword_only=True)

Then B's __init__ would take (b, c, *, a, d) as its arguments, but its comparison functions would compare the tuples as (a, b, c, d).

It would be an error for a ClassVar field to be keyword-only. I think it would be okay if an InitVar field were keyword-only, but I haven't given it a lot of thought.
History
Date User Action Args
2018-05-16 08:26:25eric.smithsetrecipients: + eric.smith, alan_du
2018-05-16 08:26:24eric.smithsetmessageid: <1526459184.99.0.682650639539.issue33129@psf.upfronthosting.co.za>
2018-05-16 08:26:24eric.smithlinkissue33129 messages
2018-05-16 08:26:24eric.smithcreate