In my experience, a dataclass with more than a few attributes makes using positional arguments unwieldy and error-prone.
I would think something like @dataclass(kwonly=bool) with default of False would be reasonably clean to implement and understand. While I appreciate supporting existing behavior for backward compatibility, I'm not so clear on the value of supporting a hybrid of positional and keyword __init__ arguments. Could you shed some light on your reasoning for supporting it? On Thu, 2021-03-11 at 00:47 -0500, Eric V. Smith 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: > > > _______________________________________________ > > Python-ideas mailing list -- > > To unsubscribe send an email to > > > > Message archived at > > Code of Conduct: > -- > Eric V. Smith > _______________________________________________ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@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/XSAYT2MFOIBYHYINDHLPR7V2WHCWRYPE/ > Code of Conduct: http://python.org/psf/codeofconduct/
_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@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/UGNLUWT4OQC2JMEXSNIJRRCC4KMBE6XJ/ Code of Conduct: http://python.org/psf/codeofconduct/
