Description
Consider this code (run with --strict-optional
):
from typing import Optional
def f():
# untyped function; often from silent import
return 0 # always returns an int
def g(x: Optional[int]) -> int
if x is None:
x = f()
return x # E: Incompatible return value type (got "Optional[int]", expected "int")
Mypy doesn't infer that x
is not None
in g
. I think this a bug -- mypy
should be permissive here.
If we wanted to fix this, we'd run into a problem: what type should x
have
after x = f()
? We don't want it to be Any
, because we don't want that
behavior in the general case. It shouldn't be int
-- f()
could be intended
to unconditionally return None
instead. To fix this, I think we need to
introduce a new special type, which I will call AnyUnion
. AnyUnion[A, B, C]
would represent a type which is allowed to be used as any of A
, B
, or
C
(similarly to how Any
is allowed to be used as any type). In this case,
we could have x
's type bound to AnyUnion[int, None]
, which would fix this
error.
Other helpful uses of AnyUnion
:
pow
will no longer need to returnAny
in builtins. Instead, it could
return the much less broadAnyUnion[int, float]
.AnyUnion[X, None]
would provide a per-variable opt-out of strict None
checking. This could be helpful for classes with delayed initialization where
a lot of effort would be needed to refactor them into a state that would work
properly with strict None checking.
Cons:
- Additional complexity of the type system affects implementation complexity and
makes things slightly harder for users to understand. - The motivating problem also exists with subclasses (with the way the binder
currently works), butAnyUnion
doesn't help much with that.
Activity
ilevkivskyi commentedon Jun 13, 2017
But doesn't #3501 (or similar) provides a better solution?
Do I understand correctly that this has been solved by PEP 526?
In general, I don't think that we really need this feature. What worries me is that in addition to making type system more complex it also can break transitivity of subtyping (or maybe better call this compatibility). IIUC your proposal, then
int <: AnyUnion[int, str] <: str
. Currently, we have only one special type that does this --Any
. Having many (user defined) types that break transitivity might lead to unexpected consequences.ilevkivskyi commentedon Jun 13, 2017
Probably it was only partially fixed by PEP 526. But for remaining cases one can just do something like:
gvanrossum commentedon Jun 13, 2017
I'm not sure this is needed all that often, but if we do, we could just spell it
Any
--Any[A, B, C]
is acceptable as a A, B or C, while plainAny
is unchanged. Alternatively, maybe this type is really the same asIntersection
(python/typing#213)?Regardless I'm not sure that in your original motivating example we should do anything different. If you want to signal at the call site that
f()
returns anint
, you can writeJukkaL commentedon Jun 13, 2017
This is probably the same feature as 'unsafe unions' that have been discussed before (though I can't find the discussion -- maybe it was in person or over email). Unsafe unions are different from
Intersection
. For example, unlike intersections, compatibility goes both ways:int
is compatible withAnyUnion[int, str]
and vice versa.My take is that this feature would complicate mypy significantly. Normal union types are already a very complicated feature, and they still aren't even fully implemented. It would be a likely cause of some user confusion, since we'd have two pretty similar but different concepts -- union types and these any/unsafe unions. If we decide to add intersection types at some point, there would be even more potential for confusion, since they are also similar in some ways to any unions. All in all, I don't think that there is enough evidence of the usefulness of the feature to support implementing it.
[-]Add `AnyUnion` type[/-][+]Assignment of Any does not get rid of Optional (add `AnyUnion` type?)[/+]JukkaL commentedon Jun 23, 2017
Solving the original issue is a priority because this may come up often when using ignored imports. I'm not convinced that adding
AnyUnion
is the right course of action, though.ilevkivskyi commentedon Jun 23, 2017
Concerning the original example:
what is wrong with
x
having typeUnion[Any, int]
after theif
block? Thus seems logical, initially it wasUnion[None, int]
but then theNone
is replaced byAny
in theif
block byx = f()
. Fortunately, such unions are not simplified anymore:Also,
Union[int, Any]
is a (non-proper) subtype ofint
so that there should be no error in the original example.ddfisher commentedon Jun 23, 2017
@ilevkivskyi: That doesn't work, as variables don't change type in general. In particular, we want to maintain this behavior:
ilevkivskyi commentedon Jun 23, 2017
@ddfisher
But there is the type binder that can already do this:
Why can't it be special-cased to re-bind to
Any
inside unions? (I agree that binding toAny
in general is clearly bad.)ddfisher commentedon Jun 23, 2017
Unless there's a really good reason, Unions should work as similarly as possible to non-Unions. I don't think this is a strong enough reason.
The binder only binds to subtypes of the declared type. If we change that, the declared type starts to become pretty meaningless.
gvanrossum commentedon Jun 23, 2017
34 remaining items