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 (
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':
, 'b': , 'c': } 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/FYDLY5... 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/EOQNTV... Code of Conduct: http://python.org/psf/codeofconduct/