-
-
Notifications
You must be signed in to change notification settings - Fork 10.8k
CI,TYP: Bump mypy to 1.4.1 #23764
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CI,TYP: Bump mypy to 1.4.1 #23764
Conversation
Some more debugging for tomorrow. The error messages differ a bit from platform to platform, though this seems to suggest that a mypy from outside Any thoughts? |
A quick google search finds this: https://stackoverflow.com/questions/64806361/installing-mypy-leads-to-shadows-library-module-error The travis-CI run sets the |
Hmmm, fun... there is another issue now about C and D drive in some runs, and the error didn't actual go away in others? So probably that was at least not the core of the issue, or any chance of a caching problem? |
It did solve the Travis failure though; and the fact that all other runs that had previously failed do so again do make me suspect that there's more going on here than a simple caching problem. |
Hmmm, some of the failures seem to be about not installing |
Hm, not sure about |
Think I may have found something here; seems the problem might be that it is directly run against something in site-packages: python/mypy#11477. It's annoying that this has now become an issue all of a sudden, though I wonder if we could run mypy directly against the numpy source? The .pyi files aren't affected by the build stage after all. |
Marking as draft for now until I have time to take a closer look. |
It should sorta work I think; the exceptions like generated That Mypy issue is a bit sad of course; they can/should just fix the thing where |
I tried to add a Mypy run with Python 3.12.0rc1 (as part of gh-24291), but it chokes on:
I suspect that this Mypy upgrade will fix that, so I haven't bothered to look at it in more detail. |
This practice is actively discouraged by mypy
Right, have yet to get mypy 1.5.1 to cooperate, but 1.4.1 now works making this PR good to go. Mypy 1.5.1 seems to truncate its type evaluation before all |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks great, thanks @BvB93. After going through the changes, the one thing that stood out to me was the "Union of scalars" thing which looks like a regression. But then I saw that you already explained it:
In addition to mypy now having implemented support for
typing.Concatenate
there seems been some changes in how it deals with the joining of super- and sub-classes. The end result as that, e.g. the likes ofnp.float64
+np.float32
were previously interpreted as producingnp.floating[_64Bit]
while not it results in anp.floating[_64Bit | _32Bit]
union.While non-ideal, this upstream change is admitetly a minor inconvenience in the grand scheme of things, mostly because the typing of dtype bitsizes in numpy is severely lacking due to the sheer number of challenges associated with it.
Fair enough, I agree it's a minor thing and we can simply ignore it for now.
I'll put back the typing_extensions
requirement in environment.yml
and then this should be good to go.
…onment.yml It's still needed, so keep it in the environment. The added import guards here match the ones already present in two other `.pyi` files. [skip cirrus] [skip circle] [skip azp] [skip travis]
I found another small issue with the use of |
Thanks Ralf. Considering In any case, keeping it for now can't hurt either way. |
We're almost at the end of the support window for Python 3.9; once we drop it, the last usages of |
Okay, in it goes. Thanks Bas! |
This PR bumps the mypy version used throughout the test suite from 0.981 to 1.3.0 (it's been a while...).
In addition to mypy now having implemented support for
typing.Concatenate
there seems been some changes in how it deals with the joining of super- and sub-classes. The end result as that, e.g. the likes ofnp.float64
+np.float32
were previously interpretted as producingnp.floating[_64Bit]
while not it results in anp.floating[_64Bit | _32Bit]
union.While non-ideal, this upstream change is admitetly a minor inconvenience in the grand scheme of things, mostly because the typing of dtype bitsizes in numpy is severely lacking due to the sheer number of challenges associated with it.
Lastly, while not implemented in this PR there's also
typing.Self
support ever since mypy 1.0.0. This type is essentially a bit of syntactic sugar to make typing involvingself
andcls
a bit easier, removing their need for hyper-specialized typevars. Something for a future PR perhaps.