On 3/13/2021 10:22 AM, Jelle Zijlstra wrote:
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 (<e...@trueblade.com
<mailto: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
<mailto:python-ideas@python.org>
To unsubscribe send an email topython-ideas-le...@python.org
<mailto:python-ideas-le...@python.org>
https://mail.python.org/mailman3/lists/python-ideas.python.org/
<https://mail.python.org/mailman3/lists/python-ideas.python.org/>
Message archived
athttps://mail.python.org/archives/list/python-ideas@python.org/message/FYDLY5CY7XTJ6TME3RCDHL53VX4AQ3WB/
<https://mail.python.org/archives/list/python-ideas@python.org/message/FYDLY5CY7XTJ6TME3RCDHL53VX4AQ3WB/>
Code of Conduct:http://python.org/psf/codeofconduct/
<http://python.org/psf/codeofconduct/>
--
Eric V. Smith
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
<mailto:python-ideas@python.org>
To unsubscribe send an email to python-ideas-le...@python.org
<mailto:python-ideas-le...@python.org>
https://mail.python.org/mailman3/lists/python-ideas.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/
<https://mail.python.org/archives/list/python-ideas@python.org/message/EOQNTVDRQK5YMR6IV2YVXI3BVSSTVXIP/>
Code of Conduct: http://python.org/psf/codeofconduct/
<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/ACSJANVGLWWDYDUY33SZOCGI32PRGKXF/
Code of Conduct: http://python.org/psf/codeofconduct/
