-
-
Notifications
You must be signed in to change notification settings - Fork 2.9k
Regression: isinstance(x, AliasOfTuple) is not supported #3068
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
Comments
Also @pkch please have a look. |
Yes, I will fix it. It's not really a type alias though, since
and I don't think we intend to support that correct? |
I have used This way or another the decision needs to be conscious. |
I think it's good to keep typing-related stuff separated from regular python code; otherwise the logic becomes very complicated - both for Python developers and for Originally, this separation was very clean: names defined in Now, unless I'm missing something, "type concepts" (i.e., names imported from I think adding more contexts where "type concepts" can be used should be done rarely and with a very strong use case. In particular, I don't think |
Actually, I just realized that there is one more context where "type concepts" can currently be used: in the second argument of
Given that, I don't see any problem with supporting more complicated type expressions, if it seems useful (including |
That code fails at runtime though ( |
@JelleZijlstra Oh lol riiiiight, my own PR #3040 is supposed to catch this statically :) I forgot. So, then I am going back to my earlier suggestion: perhaps it's better not to expand the contexts where "type concepts" are allowed beyond the current (type annotations and RHS of simple assignments). |
Fixes #3068 This would allow the use of variables inside the second argument to isinstance/issubclass, as long as those variables are assigned a tuple of types in a "visible range".
Example:
This was introduced in #2995
The text was updated successfully, but these errors were encountered: