This might be a bit of an extreme step to take, but has new syntax for this
ever been discussed? Here I am using the same indicator for keyword
arguments as in a function signature, hanging on a line by itself:
@dataclasses.dataclass
class Comparator:
a: Any
b: Any
*
key: Optional[Callable[whatever]] = None
Could also support the positional only version:
@dataclasses.dataclass
class Comparator:
/ # args become positional after this line
a: Any
b: Any
* # args become kwd args after this line
key: Optional[Callable[whatever]] = None
As far as how these standalone symbols would be parsed, I have no ideas on
that. Because of the way Dataclasses work, the / and * lines would have to
produce SOMETHING for the decorator to find. I'm just not sure what that
something would be.
But I think it looks pretty good if you're already familiar with python
function signature syntax.
Taking this to the logical conclusion:
@dataclasses.dataclass
class Comparator:
/
a: Any
b: Any
*others: Any # collect more positional args
key: Optional[Callable[whatever]] = None
**kwargs: Any # collect more kwd args
On Thu, Mar 11, 2021, 12:51 AM Eric V. Smith <e...@trueblade.com> 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:
>
> I've seen comments from Eric V Smith in this thread and in the PR. If he's
> in favor and it can be done in a backwards compatible way then he can guide
> you to acceptance and merging of your PR. But like all of us he has limited
> time.
>
> On Wed, Mar 10, 2021 at 6:15 AM Laurie O <laurie_opper...@hotmail.com>
> wrote:
>
>> I've had tens of people show interest in my proposal, asking what the
>> blocker is in acceptance. As far as I know, no Python developer has shown
>> any interest in it.
>>
>> My proposal is to automatically make any non-default fields become
>> keyword-only `__init__` parameters, with no need to have any arguments
>> passed to the `dataclass` decorator.
>>
>> My PR: https://github.com/python/cpython/pull/17322
>>
>> My previous mailing-list message:
>> https://mail.python.org/archives/list/python-ideas@python.org/message/2V2SCUFMK7PK3DVA7D77AVXWIXNTSQDK/
>> _______________________________________________
>> 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/KPVB2G64BHFGGOTXZQXT3AU7SIO5ABJE/
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>
>
> --
> --Guido van Rossum (python.org/~guido)
> *Pronouns: he/him **(why is my pronoun here?)*
> <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>
>
> _______________________________________________
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to
> python-ideas-leave@python.orghttps://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/IN3D7UQQI4HSKSCUPMU3C3RTUG6NWUKG/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
> --
> 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/NELIW4C374INVAV6Z6TAIM5ZFLT5PN52/
Code of Conduct: http://python.org/psf/codeofconduct/
