Another option is something like this (building on Ricky Teachey's suggestion):

from dataclasses import ArgumentMarker, dataclass

@dataclass

class C:

    a: Any  # positional-only

    __pos__: ArgumentMarker

    b: Any  # normal

    __kw_only__: ArgumentMarker

    c: Any  # keyword-only

The dataclass machinery would look at the double-underscored names to figure out when to change argument kind. The annotation ("ArgumentMarker") doesn't matter, but we need to put *something* there, so why not a new marker object that clarifies the purpose of the line?

Yeah, I thought of that. I guess as long as we use a dunder name and require ArgumentMarker we'd be protected from having collisions for user-named fields.

Also, this design would prevent you from switching back and forth between argument types, but I can live with that. Or we could say any dunder field name starting with "__pos" or "__kw_only" would be recognized (if the type is also ArgumentMarker). But that could be added later if there's a clamor for it, which I highly doubt.

Although due to the way dataclasses work, you can play all sorts of games with inheritance to get same effect. It's just not very user friendly.

Eric

El sáb, 13 mar 2021 a las 7:17, Eric V. Smith (<eric@trueblade.com>) escribió:

On 3/13/2021 9:33 AM, Ricky Teachey wrote:

Fwiw I read Eric's entire proposal (I like it) but totally missed the presence of single, double, triple underscores.

Which caused me to be very confused reading Matt De Valle's reply, until I went back and noticed them, and the lightbulb went on.

Based on that experience, and also Matt's comment about how people might automatically try to add a second signature directive using the same variable name, I would suggest that maybe it would be preferred, when giving examples in documentation etc, to not use underscores like this as the placeholders.... It is easy to miss that the variable names are required to be different.

Hmm. I just noticed that you can specify a class variable multiple times, without an error. Subsequent ones overwrite the prior ones in __attributes__. That's not good for my proposal, since if you use "_: dataclasses.KW_ONLY" followed by "_: dataclasses.POS_ONLY", the second one overwrites the first and you lose where the second one was:

>>> class A:
...   a: int
...   b: int
...   a: float
...   c: int
...   a: list
...
>>> A.__annotations__
{'a': <class 'list'>, 'b': <class 'int'>, 'c': <class 'int'>}

For some reason I thought this would raise an error.

This might be a showstopper for this proposal. I'm aware you could do something with metaclasses, but one core dataclasses principle is to not use metaclasses so that the user is free to use any metaclass for their own purposes, without conflict. And I think changing at this point in the game, just for this feature, won't fly.

I'll give it some more thought, but I'm not optimistic. I could still add kw_only arguments to @dataclass() and field(), but I think the best part of the proposal was saying "the rest of the fields are keyword-only".

Or, maybe we could just document this? As I said, I don't think specifying multiple KW_ONLY or POS_ONLY (or any combination) would be common. But it's an unfortunate trap waiting for the unexpecting user.

Eric

Different comment: in the other thread I liked the idea of mimicking the syntactical way of writing a function signature (although this might cause other problems):

@dataclass

class C:

    # positional only arguments required at top

    a: Any 

    Pos : '/'  # normal only after this line, can't go back

    b: Any 

    Kwd: '*'  # kwd only after this line, can't go back

    c: Any

But as Eric pointed out, there could be a lot of value in being able to go back and forth. I know think his idea is better.

BIKE SHED:

If switching back and forth does win out, I think we should NOT try to use the characters '/' and '*' to specify the signature directives because they would lead the reader to believe they work the same as in a function signature.

Aside from the issue if going back and forth, in Eric's proposal the positional directive comes *before* the positional arguments, rather than after like in a function signature. Since this is so different, please don't try to use '/'.

_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-leave@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/FYDLY5CY7XTJ6TME3RCDHL53VX4AQ3WB/
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-leave@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/EOQNTVDRQK5YMR6IV2YVXI3BVSSTVXIP/
Code of Conduct: http://python.org/psf/codeofconduct/

-- 
Eric V. Smith