[red-knot] Infer precise types for len() calls#14599
Conversation
|
carljm
left a comment
There was a problem hiding this comment.
Thank you!! A few comments.
crates/red_knot_python_semantic/resources/mdtest/expression/len.md
Outdated
Show resolved
Hide resolved
crates/red_knot_python_semantic/resources/mdtest/expression/len.md
Outdated
Show resolved
Hide resolved
crates/red_knot_python_semantic/resources/mdtest/expression/len.md
Outdated
Show resolved
Hide resolved
5420238 to
27db683
Compare
crates/red_knot_python_semantic/resources/mdtest/expression/len.md
Outdated
Show resolved
Hide resolved
carljm
left a comment
There was a problem hiding this comment.
This looks quite close! Thanks for your patience with all the review comments.
I think it makes sense to leave the diagnostics as TODO here, because it will be a lot easier to emit these diagnostics once #14760 lands (we won't have to return some indicator such that inference emits the diagnostic, we'll be able to just emit it directly where we find the issue.)
crates/red_knot_python_semantic/resources/mdtest/expression/len.md
Outdated
Show resolved
Hide resolved
|
@MichaReiser Ok, let's discuss those details elsewhere. The only part that's relevant here is to say that I think accumulators will be super useful in type checking and make a lot of things much simpler and easier, so I think we really want/need it, even if it requires more work on handling suppressions. |
Looks like all comments in this review were addressed.
|
Thanks! And great find on the string-literal-unpacking issue. Merging. |
Summary
Resolves #14598.
Test Plan
Markdown tests.