[ty] propagate classmethod-ness through decorators returning Callables#21958
[ty] propagate classmethod-ness through decorators returning Callables#21958
Conversation
Diagnostic diff on typing conformance testsNo changes detected when running ty on typing conformance tests ✅ |
|
0a5ad34 to
71dc7f3
Compare
|
| Lint rule | Added | Removed | Changed |
|---|---|---|---|
missing-argument |
0 | 146 | 0 |
invalid-argument-type |
0 | 76 | 0 |
| Total | 0 | 222 | 0 |
71dc7f3 to
dac92e2
Compare
CodSpeed Performance ReportMerging #21958 will not alter performanceComparing Summary
|
|
874dc7e to
8871fdd
Compare
dhruvmanila
left a comment
There was a problem hiding this comment.
This sounds like a reasonable approach.
I was wondering about what Alex mentioned last Friday which is whether we could start modeling these decorators directly using the typeshed's definition. I think it might be possible for staticmethod but classmethod requires Concatenate support. But even after that I'm not sure how could we signal ty to pass the implicit cls argument to the callable.
|
Yeah, I think Carl's analysis demonstrates that we will need some version of this even if we go with the approach I outlined on Friday (which may still be worth doing on its own merits after |
dac92e2 to
6756bac
Compare
6756bac to
88c12ca
Compare
Fixes astral-sh/ty#1787
Summary
Allow method decorators returning Callables to presumptively propagate "classmethod-ness" in the same way that they already presumptively propagate "function-like-ness". We can't actually be sure that this is the case, based on the decorator's annotations, but (along with other type checkers) we heuristically assume it to be the case for decorators applied via decorator syntax.
Test Plan
Added mdtest.