Repository navigation
Do not narrow types to Never with binder - #18972
ilevkivskyi merged 1 commit into
Conversation
Sorry, something went wrong.
|
Diff from mypy_primer, showing the effect of this PR on open source code: pandas (https://github.com/pandas-dev/pandas)
- pandas/io/formats/style.py:1903: error: "Never" has no attribute "shape" [attr-defined]
- pandas/io/formats/style.py:1906: error: "Never" has no attribute "shape" [attr-defined]
streamlit (https://github.com/streamlit/streamlit)
+ lib/streamlit/dataframe_util.py: note: In function "convert_anything_to_list":
+ lib/streamlit/dataframe_util.py:927:17: error: List item 0 has incompatible type "Union[str, int, float]"; expected "V_co" [list-item]
static-frame (https://github.com/static-frame/static-frame)
- static_frame/core/frame.py:5610: error: Unused "type: ignore" comment [unused-ignore]
spark (https://github.com/apache/spark)
+ python/pyspark/core/context.py:837: error: Unused "type: ignore" comment [unused-ignore]
+ python/pyspark/core/context.py:838: error: Unused "type: ignore" comment [unused-ignore]
+ python/pyspark/ml/connect/readwrite.py:98: error: Redundant cast to "JavaEstimator[Any]" [redundant-cast]
+ python/pyspark/ml/connect/readwrite.py:101: error: Redundant cast to "JavaEvaluator" [redundant-cast]
Tanjun (https://github.com/FasterSpeeding/Tanjun)
- tanjun/parsing.py:588: error: "Never" has no attribute "__iter__" (not iterable) [attr-defined]
- tanjun/dependencies/limiters.py:851: error: "Never" has no attribute "unlock" [attr-defined]
|
Sorry, something went wrong.
|
This impacts several existing issues: sterliakov/mypy-issues#27 |
Sorry, something went wrong.
|
Hm, interesting... As I said, it is gray area, but IMO most of the impact looks positive, I will however take a closer look later today or tomorrow. |
Sorry, something went wrong.
|
OK, I went through mypy_primer and the mypy-issues, overall I found ~dozen cases where this PR either completely fixes an issue or improves it, and only a single case where it makes things (slightly) worse. Which kind of makes sense, in tricky situations people usually expect mypy to trust the most recent type information available. @JukkaL unless you have objections, I am going to merge this soon. |
Sorry, something went wrong.
JukkaL
left a comment
There was a problem hiding this comment.
I agree that the new behavior seems better.
Sorry, something went wrong.
Fixes #18967
Fixes #16494
Fixes #15793
Fixes #12949
As you can see from updated test cases, it is kind of gray area, so whether we go this way will depend on the mypy_primer results (and also potentially on Dropbox internal code bases, where the above issue may cause problems).