-
-
Notifications
You must be signed in to change notification settings - Fork 2.8k
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
ErrorType is never actually used #3063
Comments
I think @JukkaL is also working on a solution for that. |
Well, it seems you're right, killing it was really easy. |
JukkaL
pushed a commit
that referenced
this issue
Apr 3, 2017
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
...or at least I think so?
Anyway, I was working on a fix for #2998, and I just happened to stumble upon
ErrorType
. It seemed like the perfect potential solution: make an uninferred variable of typeErrorType
, that way you won't get future errors deriving from it. Just to see, though I ranucg ErrorType
over mypy's codebase. Only instances I found were:types.py
.if isinstance(xyz, ErrorType): return ErrorType()
or similar checks.join_types
claiming non-existent joins returnErrorType
. Actually, it never does so (it seems to just fallback toUnion.make_simplified_union
.self.err
inTypeFixture
's constructor. This is solely used in the tests to make sure joins handleErrorType
correctly...even though it's never actually used outside of that.So it seems pretty much impossible for an
ErrorType
to wander into...anywhere, really. Have its uses just declined over time?The text was updated successfully, but these errors were encountered: