You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
mypy happily accepts anext_via_instance, but in anext_via_type it fails with:
main.py:10: error: Incompatible return value type (got "_T_co", expected "T") [return-value]
main.py:10: error: Argument 1 has incompatible type "AsyncIterator[T]"; expected "AsyncIterator[_T_co]" [arg-type]
If I add a reveal_type(anext) in anext_via_type:
main.py:10: note: Revealed type is "def (self: typing.AsyncIterator[_T_co`1]) -> typing.Awaitable[_T_co`1]"
This behavior doesn't seem to be a recent change; it showed up on every version I spot-checked on the playground, and is still present on master. From the error message it looks like some kind of issue with TypeVar inference, but I'm not an expert.
(I'm trying to write something like anext_via_type in order to mimic the interpreter's behavior accessing a magic method in a specific circumstance; it won't accept an instance attribute, only a class attribute, so I don't want to accept an instance attribute either.)
The text was updated successfully, but these errors were encountered:
Fixespython#18024Fixespython#18706Fixespython#17734Fixespython#15097Fixespython#14814Fixespython#14806Fixespython#14259Fixespython#13041Fixespython#11993Fixespython#9585Fixespython#9266Fixespython#9202Fixespython#5481
This is a fourth "major" PR toward
python#7724. This is one is
watershed/crux of the whole series (but to set correct expectations,
there are almost a dozen smaller follow-up/clean-up PRs in the
pipeline).
The core of the idea is to set current type-checker as part of the
global state. There are however some details:
* There are cases where we call `is_subtype()` before type-checking. For
now, I fall back to old logic in this cases. In follow up PRs we may
switch to using type-checker instances before type checking phase (this
requires some care).
* This increases typeops import cycle by a few modules, but
unfortunately this is inevitable.
* This PR increases potential for infinite recursion in protocols. To
mitigate I add: one legitimate fix for `__call__`, and one temporary
hack for `freshen_all_functions_type_vars` (to reduce performance
impact).
* Finally I change semantics for method access on class objects to match
the one in old `find_member()`. Now we will expand type by instance, so
we have something like this:
```python
class B(Generic[T]):
def foo(self, x: T) -> T: ...
class C(B[str]): ...
reveal_type(C.foo) # def (self: B[str], x: str) -> str
```
FWIW, I am not even 100% sure this is correct, it seems to me we _may_
keep the method generic. But in any case what we do currently is
definitely wrong (we infer a _non-generic_ `def (x: T) -> T`).
---------
Co-authored-by: hauntsaninja <[email protected]>
Co-authored-by: Shantanu <[email protected]>
Uh oh!
There was an error while loading. Please reload this page.
Consider the following code:
mypy happily accepts
anext_via_instance
, but inanext_via_type
it fails with:If I add a
reveal_type(anext)
inanext_via_type
:This behavior doesn't seem to be a recent change; it showed up on every version I spot-checked on the playground, and is still present on master. From the error message it looks like some kind of issue with TypeVar inference, but I'm not an expert.
(I'm trying to write something like
anext_via_type
in order to mimic the interpreter's behavior accessing a magic method in a specific circumstance; it won't accept an instance attribute, only a class attribute, so I don't want to accept an instance attribute either.)The text was updated successfully, but these errors were encountered: