-
Notifications
You must be signed in to change notification settings - Fork 250
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
Allow bare typing.ClassVar
qualifiers
#1931
base: main
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The substance of this looks good to me, thanks for the PR!
docs/spec/class-compat.rst
Outdated
inferred as some type to which this value is :term:`assignable` (in this | ||
case, either ``int``, ``Literal[2]``, or ``Any``). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The listed options are not the only choices here, I'd prefer not to imply that they are. (I think a strong case can be made that inferring Any | Literal[2]
is the most correct option, from a gradual-typing perspective.) I'm fine with just listing the simpler options that you have here, but we shouldn't imply that it's an exhaustive list.
inferred as some type to which this value is :term:`assignable` (in this | |
case, either ``int``, ``Literal[2]``, or ``Any``). | |
inferred as some type to which this value is :term:`assignable` (for example, | |
``int``, ``Literal[2]``, or ``Any``). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is what I wanted to write out to begin with, but I realize my wording is wrong indeed :)
docs/spec/class-compat.rst
Outdated
case, either ``int``, ``Literal[2]``, or ``Any``). | ||
|
||
If the ``ClassVar`` qualifier is used without any assigned value, the type | ||
should be inferred to an unknown static type (such as :ref:`Any`). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The only dynamic type discussed in the typing spec is Any
, so it's a bit odd to imply here that there would be others. Most type checkers do distinguish between different "origins" of Any
, and some do so with a variant of Any
named Unknown
, but as far as the spec is concerned these are all just Any
.
should be inferred to an unknown static type (such as :ref:`Any`). | |
should be inferred as :ref:`Any`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was wondering if such a concept of an unknown static type, as written in the referenced any
section:
typing/docs/spec/special-types.rst
Lines 6 to 14 in fafcdeb
.. _`any`: | |
``Any`` | |
------- | |
``Any`` represents an unknown static type. | |
Every type is :term:`assignable` to ``Any``, and ``Any`` is assignable to every | |
type. |
would be worth specifying, and that's why I chose the same phrasing. But let's not complicate things, I'll go with Any.
This change to the spec looks reasonable to me. If this is accepted, someone will need to write conformance tests for it. @Viicos, if you're willing, you could include the conformance test updates in the same PR. |
0e355b7
to
97334a2
Compare
As per https://discuss.python.org/t/81705.