[Python-ideas] Re: dataclasses keyword-only fields, take 2

16 Mar 2021

      ...
On Tue, Mar 16, 2021 at 11:59 AM Eric V. Smith mailto:eric@trueblade.com> 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
On 3/16/2021 12:16 PM, Ricky Teachey wrote:
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:
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.
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')

Gives:

ValueError: binary mode doesn't take an encoding argument

Eric
...
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
-- 
Eric V. Smith