bpo-33129: Add kwarg-only option to dataclass by alanhdu · Pull Request #6238 · python/cpython (original) (raw)

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Conversation10 Commits3 Checks0 Files changed

Conversation

This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.Learn more about bidirectional Unicode characters

[ Show hidden characters]({{ revealButtonHref }})

alanhdu

@the-knights-who-say-ni

Hello, and thanks for your contribution!

I'm a bot set up to make sure that the project can legally accept your contribution by verifying you have signed the PSF contributor agreement (CLA).

Unfortunately our records indicate you have not signed the CLA. For legal reasons we need you to sign this before we can look at your contribution. Please follow the steps outlined in the CPython devguide to rectify this issue.

Thanks again to your contribution and we look forward to looking at it!

@alanhdu

So I guess there are two things to discuss:

(1) How does this work with inheritance? In this PR, I chose to take the simplest route and say that if C is a kwarg-only dataclass, then all of its sub and super dataclasses must also be kwarg-only (similar to how frozen works)

(2) What to call the flag? I choose kwarg_only, although I could see kwargs_only, keyword_only, kw_only, etc. I've got no real preference here 😆.

@the-knights-who-say-ni

Hello, and thanks for your contribution!

I'm a bot set up to make sure that the project can legally accept your contribution by verifying you have signed the PSF contributor agreement (CLA).

Unfortunately our records indicate you have not signed the CLA. For legal reasons we need you to sign this before we can look at your contribution. Please follow the steps outlined in the CPython devguide to rectify this issue.

Thanks again to your contribution and we look forward to looking at it!

@ericvsmith

We'll need to discuss this on python-ideas first. But since 3.8 is 1.5+ years away, I don't think we'll take any actions on it until dataclasses have some real-world use. Maybe look at attrs or similar projects and see what they do (or if they've had any discussions on this topic) before bringing it up on the mailing list.

@brettcannon

Closing as the CLA has not been signed within the last month.

@bm371613

@brettcannon How can this be pushed forward? The author apparently has lost interest or didn't want to sign the CLA. If I want this feature to be added, do I need to try to unsee the code changes here and implement the exact same thing myself, hoping it's not too similar?

@ericvsmith

I'm not sure it makes sense to move forward until we have a firm design. There are various proposals for making all params keyword only, some params keyword only (via Field), and various options with what to do when inheriting. I think working this out on python-ideas first, then recording the decisions in the bpo issue, then writing a patch is the correct order.

I'd also like to do some research on what attrs does, if that's not already been done.

I'm not sure if this rises to the level of needing a PEP, but there are a lot of issues to work through.

@bm371613

@ChrisBarker-NOAA

PIng! has anything come of this? I think it'd be a great feature.

@Hyaxia

PIng! has anything come of this? I think it'd be a great feature.

Same here, great feature to be added!