-
-
Notifications
You must be signed in to change notification settings - Fork 2.9k
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
Using x = property(get_x)
in a class definition misbehaves
#16827
Labels
Comments
This comment was marked as duplicate.
This comment was marked as duplicate.
JelleZijlstra
added
the
topic-descriptors
Properties, class vs. instance attributes
label
Jan 26, 2024
The |
EliahKagan
added a commit
to EliahKagan/GitPython
that referenced
this issue
Mar 8, 2024
HEAD inherits its commit attribute from SymbolicReference, which defines it as a property using an explicit function call to `property`, rather than using it as a decorator. Due at least to python/mypy#16827, mypy has trouble with this. Currently that assignment in SymbolicReference is marked as type[ignore], which suppresses a type error (or something mypy regards as one) in the call itself. Even without that type comment, the type of the SymboilicReference instance attribute produced by the property is inferred as Any. This commit does not change that. This commit replaces the HEAD class's partially successful attempt to annotate `commit` as `self.commit` in `__init__` with a fully recognized annotation for `commit` in the class scope (which is interpreted as an instance attribute). Merely removing the annotation in `__init__` is sufficient to make the mypy error for it go away, but this causes the inferred type of `x.commit` when `x` is a `HEAD` instance to be inferred as Any rather than the desired specific type Commit. That is why this also adds an annotation to the class to achieve that without causing its own mypy error as the old one did. Once the SymbolicReference.commit property has a more specific static type, however that is to be achieved, there will be no need for the annotation added in the HEAD class body here. (This differs from the situation in 3aeef46 before this, where Diffable does not inherit any `repo` attribute--and is intended not to--and therefore had to introduce an annotation for it, for mypy to accept it.)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
[It's difficult to believe this hasn't been reported before, but, with apologies, I haven't been able to find an open issue describing this.]
Bug Report
Mypy doesn't support using
@property
as a function in a class definition. This makes it challenging to work around #6700.We might expect these declarations to be similar (a11y version follows):
Accessible version of the above
But in mypy, the left form results in
foo
having typeAny
, whether accessed on the class itself or an instance.To Reproduce
mypy-play.net: gist
Expected Behavior
controlcase
andtestcase
should be indistinguishableActual Behavior
Mypy doesn't understand
@property
when used as a function.Your Environment
mypy.ini
(and other config files): noneThe text was updated successfully, but these errors were encountered: