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?

El sáb, 13 mar 2021 a las 7:17, Eric V. Smith (<e...@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.orghttps://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-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/EOQNTVDRQK5YMR6IV2YVXI3BVSSTVXIP/
> 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/XTOTSDQLQIA3JGZR3TK5ONBQQ74UC2WL/
Code of Conduct: http://python.org/psf/codeofconduct/

Reply via email to