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
{{ message }}
Repository navigation
Unions that include Any should probably not just become Any #1642
Currently, UnionType.make_simplified_union will return an Any if any of the types passed in are Any. This probably doesn't make sense.
As a simple example, if we have:
deff(x: Union[str, Any]) ->int:
returnx+1
(This example looks a little silly, but this Any might not be explicit -- it could e.g. be a class from a --silent-imports module.)
This is clearly unsafe. I think we should still require an isinstance check.
What's the real example where you got this? ISTM that if a value can be Any then mypy should shut up about it, not try to be picky. If we consider a type to be a set of values, then Any is the set of all values, so adding strings to it doesn't do anything.
I think Any is the one type that can't be thought of as a set of values. (For example, if we think of Any as the set of all values, then you should only be able to do things to it that can be done to all values... but that's not the case.)
I wasn't directly bitten by this, but I realized this was a bit fishy while I was reviewing #1639.
Hm... The situation in #1639 is a little different. The expression in the except clause must be either an exception or a tuple of exceptions, but it cannot be a tuple of tuples of exceptions. So it is incorrect to treat it as a union, and the code is right to insist that each individual value in the tuple is compatible with BaseException -- not that the tuple as a whole (or the tuple turned into a union) is compatible with BaseException.
I still don't think that from your original example above it follows that Union[X, Any] should be treated differently than Any.
You can still use isinstance(x, X) if you want uses of x to be checked more precisely as an X.
Preserving Any inside a union would potentially let us catch some more errors, but figuring out all the implications of this could be a little tricky. I'd rather not worry about this right now as the current behavior is quite reasonable and it conforms to the spirit of how Any works in general. If we see unions like these in user code with non-trivial frequency then we might want to reconsider.
Activity
gvanrossum commentedon Jun 4, 2016
What's the real example where you got this? ISTM that if a value can be Any then mypy should shut up about it, not try to be picky. If we consider a type to be a set of values, then Any is the set of all values, so adding strings to it doesn't do anything.
ddfisher commentedon Jun 4, 2016
I think
Anyis the one type that can't be thought of as a set of values. (For example, if we think ofAnyas the set of all values, then you should only be able to do things to it that can be done to all values... but that's not the case.)I wasn't directly bitten by this, but I realized this was a bit fishy while I was reviewing #1639.
gvanrossum commentedon Jun 4, 2016
Hm... The situation in #1639 is a little different. The expression in the except clause must be either an exception or a tuple of exceptions, but it cannot be a tuple of tuples of exceptions. So it is incorrect to treat it as a union, and the code is right to insist that each individual value in the tuple is compatible with BaseException -- not that the tuple as a whole (or the tuple turned into a union) is compatible with BaseException.
I still don't think that from your original example above it follows that
Union[X, Any]should be treated differently thanAny.You can still use
isinstance(x, X)if you want uses of x to be checked more precisely as an X.JukkaL commentedon Jun 9, 2016
Preserving
Anyinside a union would potentially let us catch some more errors, but figuring out all the implications of this could be a little tricky. I'd rather not worry about this right now as the current behavior is quite reasonable and it conforms to the spirit of howAnyworks in general. If we see unions like these in user code with non-trivial frequency then we might want to reconsider.gvanrossum commentedon Jun 9, 2016
Let's close this issue then.
ddfisher commentedon Aug 31, 2016
I've since seen this issue in user code, and we're more agreed on this being a good idea. Reopening so we don't forget about this.
gvanrossum commentedon Sep 1, 2016
Should probably also be brought up in the python/typing tracker.
JukkaL commentedon Jun 13, 2017
This was implemented a while ago.