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-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/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/
