On 3/16/2021 12:16 PM, Ricky Teachey wrote:
On Tue, Mar 16, 2021 at 11:59 AM Eric V. Smith <[email protected]
<mailto:[email protected]>> 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:
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
_______________________________________________
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/[email protected]/message/36O5LCMLDWP6NZZQIEFUA2DMTNOVA7N3/
Code of Conduct: http://python.org/psf/codeofconduct/
