KotlinIsland / KotlinIsland/basedmypy
Support asymmetric properties
- Dominant language
- Python
- Stars
- 202
- Forks
- 6
- PR merge metrics
- No merged PRs in 30d
Description
Currently asymmetric properties are not supported by `mypy`. It `mypy` this is considered a bug with high priority ([issue](https://github.com/python/mypy/issues/3004)).
`basemypy` decided to go this way further and assume that properties are symmetric even without annotations on setter. To quote [docs](https://kotlinisland.github.io/basedmypy/based_features.html#overload-implementation-inference):
> The types in overload implementations (including properties) can be inferred:
> ```py
> class A:
> @property
> def foo(self) -> int: ...
> @foo.setter
> def foo(self, value): ... # no need for annotations
>```
I suggest to think about this solution and consider allowing asymmetric properties, because cases like below with value normalization are quire common.
Code sample:
```py
from collections.abc import Iterable
class A:
def __init__(self):
self._foo: list[str] = []
@property
def foo(self) -> list[str]:
return self._foo
@foo.setter
def foo(self, __val: Iterable[str]):
self._foo = list(__val)
a = A()
reveal_type(a.foo) # N: Revealed type is "list[str]"
a.foo = ('a',) # E: Incompatible types in assignment (expression has type "(str,)", variable has type "list[str]") [assignment]
```
Contributor guide
Research direction
Start by reproducing the asymmetric-property example in the issue and reviewing the linked mypy issue and basedmypy documentation. Done means the getter exposes list[str] while the setter accepts Iterable[str] without producing the shown assignment error, with the existing type-checking behavior preserved.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- devtools
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100