On 3/16/2021 12:16 PM, Ricky Teachey wrote:
On Tue, Mar 16, 2021 at 11:59 AM Eric V. Smith <email@example.com mailto:firstname.lastname@example.org> wrote:
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." :)
I hope I'm not coming off as unappreciative of anyone's comments. I asked for them! And it's because of comments on the first version of this proposal that I've modified it to become this one.
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:
The above would be an invalid combination. So it doesn't prohibit it but it makes it a bit harder to add it later.
That's what my previous proposal suggested, and I still think it's okay. I think "kw_only=True" is clearer than "mark=dataclasses.KW_ONLY". I don't think field(kw_only=True) will be used very often, and I think field(posit_only=True) would be used almost never. So I'm going to optimize the API for the more common usage.
And I don't mind checking for invalid combinations. There's already plenty of that in dataclasses, just check out the charts at the top of dataclasses.py and look for "raise".
There's also lots of this checking already in Python:
open('foo', 'b', encoding='utf-8')
ValueError: binary mode doesn't take an encoding argument
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
"I've never met a Kentucky man who wasn't either thinking about going home or actually going home." - Happy Chandler