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/