Allow passing a callable with type vars in self types #18401
Conversation
This comment has been minimized.
This comment has been minimized.
|
@A5rocks I will check this one later, sorry (with all the reviews I don't have time/energy to finish my PR adding support for properties with different setter types). |
|
This also makes the output on #14322 better, though I think the issue has already been solved: #------ difference on issues/14322/blocks.json
+ /tmp/tmpcftql_gf:49: note: Revealed type is "def [P] (b_param_1: builtins.str, *P.args, **P.kwargs) -> __main__.B[P`<id>, __main__.ADerived]"
+ Success: no issues found in 1 source file
- /tmp/tmpcftql_gf:47: error: Need type annotation for "BADerived" [var-annotated]
- /tmp/tmpcftql_gf:49: note: Revealed type is "def (*Any, **Any) -> __main__.B[[a_param_1: builtins.float], __main__.ADerived]"
- Found 1 error in 1 file (checked 1 source file)
#------ |
|
According to mypy_primer, this change doesn't affect type check results on a corpus of open source code. ✅ |
|
I just ran into this again on another project, it would be nice to have this merged! See python-trio/trio#3260 for that use case. |
|
@ilevkivskyi just bumping this! |
|
I am keeping postponing this, but unfortunately I still have a lot of work on the whole |
|
@ilevkivskyi ping, curious if things are less chaotic now |
|
Sorry for delay, it has been a year now, LOL. Unfortunately, a bit busy right now. I will try to go through old PRs at some point soon. |
3 participants
Fixes #18400
@ilevkivskyi I'd appreciate if you checked the logic in this PR because I enabled polymorphic inference for binding self and had to handle
[T] () -> (T) -> Tinto() -> [T] (T) -> T... I remember seeing this kind of push down logic before, but I can't remember if there's a common function or if there is an issue with doing that.