This might be a bit of an extreme step to take, but has new syntax for this ever been discussed? Here I am using the same indicator for keyword arguments as in a function signature, hanging on a line by itself: @dataclasses.dataclass class Comparator: a: Any b: Any * key: Optional[Callable[whatever]] = None Could also support the positional only version: @dataclasses.dataclass class Comparator: / # args become positional after this line a: Any b: Any * # args become kwd args after this line key: Optional[Callable[whatever]] = None As far as how these standalone symbols would be parsed, I have no ideas on that. Because of the way Dataclasses work, the / and * lines would have to produce SOMETHING for the decorator to find. I'm just not sure what that something would be. But I think it looks pretty good if you're already familiar with python function signature syntax. Taking this to the logical conclusion: @dataclasses.dataclass class Comparator: / a: Any b: Any *others: Any # collect more positional args key: Optional[Callable[whatever]] = None **kwargs: Any # collect more kwd args On Thu, Mar 11, 2021, 12:51 AM Eric V. Smith <eric@trueblade.com> wrote:
As I've said before, I'm not opposed to the feature of keyword-only arguments. I think it would be a great addition.
However, the proposal from Laurie O is only for changing fields without default values following fields with default values to be keyword-only. At least that's how I understand it.
So, that means that:
@dataclasses.dataclass class Point: x: int = 0 y: int z: int t: int = 0
Would generate a __init__ with this signature:
def __init__(self, x=0, *, y, z, t=0):
While it's an interesting application, I think that's just too limiting. Among other things, I can't define a dataclass where all fields are keyword-only, or a class where there's only a single field and it's keyword-only. I also have to have at least one keyword-only field (here, y) that has no default value. z and t can have defaults, but not y.
What I'd like to see is some way of having keyword-only arguments, with or without defaults. And I'd also like to see if we could get support for positional-only arguments at the same time.
I'm not sure of the best way to achieve this. Using flags to field() doesn't sound awesome, but could be made to work. Or maybe special field names or types? I'm not crazy about that, but using special types would let you do something like:
@dataclasses.dataclass class Point: x: int = 0 _: dataclasses.KEYWORD_ONLY y: int z: int t: int = 0
And the dataclasses machinery would ignore the "_" field except for making everything after it keyword-only. Here the name "_" isn't special: any field (of any name) that's of type dataclasses.KEYWORD_ONLY would be ignored except for the keyword-only changing behavior. In some ways, it's like dataclasses.ClassVar, where the type is treated specially and the field doesn't become a __init__ argument.
There are also issues with inheritance that would need to be thought through. This idea could also be extended for positional-only.
I'm open to other suggestions.
Eric On 3/10/2021 10:22 AM, Guido van Rossum wrote:
I've seen comments from Eric V Smith in this thread and in the PR. If he's in favor and it can be done in a backwards compatible way then he can guide you to acceptance and merging of your PR. But like all of us he has limited time.
On Wed, Mar 10, 2021 at 6:15 AM Laurie O <laurie_opperman@hotmail.com> wrote:
I've had tens of people show interest in my proposal, asking what the blocker is in acceptance. As far as I know, no Python developer has shown any interest in it.
My proposal is to automatically make any non-default fields become keyword-only `__init__` parameters, with no need to have any arguments passed to the `dataclass` decorator.
My PR: https://github.com/python/cpython/pull/17322
My previous mailing-list message: https://mail.python.org/archives/list/python-ideas@python.org/message/2V2SCU... _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/KPVB2G... Code of Conduct: http://python.org/psf/codeofconduct/
-- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-c...>
_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.orghttps://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/IN3D7U... Code of Conduct: http://python.org/psf/codeofconduct/
-- Eric V. Smith
_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/XSAYT2... Code of Conduct: http://python.org/psf/codeofconduct/