-
Notifications
You must be signed in to change notification settings - Fork 53
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
An alternative to typing.ClassVar? #61
Comments
+1 for -1 for I can't figure out why one would avoid just importing the If someone has a different module importable as |
My concern about importing I agree that we can just continue using I also agree that adding param to It seems like using its annotation is the right way to go, so the question is: other than using Maybe if |
Aside from the standard library usage case, the other main reason for not wanting to import the If you combine it with the
In essense, where we now have |
@ncoghlan What is |
One of the benefits of being in the stdlib is that we only need to support one version of Python. In 3.7 For forward-compatibility, |
@taleinat The
Then the |
@ncoghlan, thanks for the info, I hadn't known that |
Father forgive me for I have sinned. ref ericvsmith/dataclasses#61
Removal of As for "dataclasses should be unaware of typing", that sounds reasonable if ClassVar is meant to be used by data classes users anyway.
Also note that while this makes importing |
From the OP:
If we remove
I don't like any of the schemes proposed for this in this thread. They all seem way too harebrained, and would require mypy to jump through extra hoops. If typing is removed, then stdlib modules had better not try to use |
I agree that all of the proposed solutions seem sketchy. Why would it be dataclasses that own the singledispatch registry for |
Sounds good. You can close this issue. |
@ericvsmith's suggested approach sounds reasonable to me, too. |
In issue #14 we added support for
typing.ClassVar
annotations. If an annotation is aClassVar
, then it's considered to not be a field (that is, it's not set on instances of the dataclass, it's not in__init__
, etc.).There's ongoing discussion on python-ideas and python-dev about dropping the typing module from the stdlib.
I'm wondering what we should do about
ClassVar
if typing is in fact dropped from the stdlib.Currently, the code doesn't import typing. It just looks for
"typing"
in sys.modules, and if that's present, assumes it's the typing module and looks inside of it forClassVar
. I think this is a good approach. However, if typing is no longer part of the stdlib, I guess it's possible for another module named typing to be used in its place, and then I need to be more defensive about looking insidesys.modules['typing']
. Is that case worth worrying about? I sort of think it's not, although it would be easy enough to add agetattr(typing, 'ClassVar')
to the code.The other thing to worry about is: what if typing is removed, but something in the stdlib wants to have a dataclass with a ClassVar? In https://mail.python.org/pipermail/python-dev/2017-November/150176.html, @ncoghlan suggested having dataclasses create its own ClassVar. Another option that's just as good, although the syntax is somewhat worse, is to add a param to
field()
that says "this isn't really a field". Something like:In either event, mypy would need to know about it, to know that
__init__
for the class would only have one parameter,x
.If we go with any of these approaches, I think we should still keep the code in dataclasses that understands real
typing.ClassVar
fields. That seems like the most natural way to write code, outside of the stdlib.The text was updated successfully, but these errors were encountered: