On 3/16/2021 10:06 AM, Ricky Teachey
wrote:
...
I think I prefer it, too. But what about using something
like `mark=dataclasses.KW_ONLY` rather than `kw_only=True`
(in the field constructor)? So it isn't an on/off switch and
as to leave open the door for positional arguments? Is that
door to be totally closed? I'm not here to argue in favor of
it necessarily, just asking whether we really want to close
the door more tightly against it than we have to.
I don't see how my proposal prohibits a future use of positional
arguments, much as '/' was added after '*' for positional
arguments for functions.
Eric
Here I am only trying to help by pointing out a few things that might be worth considering. However I am FULLY willing to be told "Rick: we've been designing language features a long time and, trust me, none of this a big deal." :)
It doesn't prohibit it, but choosing `kw_only` as the argument name (in both dataclasses.dataclass and dataclasses.field) semantically limits it to only being used as an on/off switch for a kw-only setting. Later, if it became desirable to add positional only, you'd need to add another separate on/off setting for it (say, `posit_only`) and then you'd end up in situations where the flag combos could be in conflict, and you have to check for that conflict:
kw_only=True, posit_only=True
The above would be an invalid combination. So it doesn't prohibit it but it makes it a bit harder to add it later.
And is there another possible "setting".... possibly a bit exotic, maybe something that would end up being specific to dataclasses... that would also exclude OR require one or both of either/or kw_only and posit_only...? I am not sure, but maybe there is. And in that case you'd end up with a third on/off switch, and some other set of possibly ponderous checking:
kw_only=True, exotic_setting=True
posit_only=True, exotic_setting=True
---
Ricky.
"I've never met a Kentucky man who wasn't either thinking about going home or actually going home." - Happy Chandler