You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Generate an error if a type from the stdlib numbers module is used in an annotation. Use a dedicated error code so that the error can be easily enabled and disabled. Initially this would be disabled by default, but we'd enable it by default in the next major mypy release.
Pitch
These types are very rarely useful for static type checking but often cause confusion when users try to use them. If we'd generate an error by default with a clarifying note, users would be less likely to go down this rabbit hole. Any existing, legitimate use cases (which I expect to be rare) would still be supported by explicitly disabling the error code.
This would be an alternative way to approach #3186.
The text was updated successfully, but these errors were encountered:
I recently had a friend (kind of new to Python and and Python typing) start using some of those numbers types.
Remembering some of my past experiences with it, I said to him "No, no. You don't want to do that."
And my mistake of using the numbers module years ago is still stuck making a mess in another project, where we have to keep it for backwards compatibility.
Feature
Generate an error if a type from the stdlib
numbers
module is used in an annotation. Use a dedicated error code so that the error can be easily enabled and disabled. Initially this would be disabled by default, but we'd enable it by default in the next major mypy release.Pitch
These types are very rarely useful for static type checking but often cause confusion when users try to use them. If we'd generate an error by default with a clarifying note, users would be less likely to go down this rabbit hole. Any existing, legitimate use cases (which I expect to be rare) would still be supported by explicitly disabling the error code.
This would be an alternative way to approach #3186.
The text was updated successfully, but these errors were encountered: