Repository navigation
type alias to union is invalid in runtime context #5354
Description
As of MyPy 0.620:
# aliases.py
from typing import Union
x = Union[int, str]
def y() -> None:
print(x)This produces the error:
aliases.py:5: error: The type alias to Union is invalid in runtime context
However, type variables are quite useful in "runtime context" in order to implement things like serialization; for example, https://github.com/Tinche/cattrs makes heavy use of introspecting Union objects to determine which types are valid.
Those of us hacking around code like this have known that the current API for enumerating the members of a Union was private & internal, and not for public consumption, so we've been keeping pace with implementation details while waiting for a public API to get this information to emerge. These errors are super annoying because they imply the only future-looking direction for this type of code will involve manually re-typing the same list of types for every union alias defined anywhere.
Can this change be backed out? If not, is there any guidance for how to define a Union such that it is introspectable?
Activity
glyph commentedon Jul 13, 2018
I guess this was a result of #5221 ?
ilevkivskyi commentedon Jul 14, 2018
From mypy's point of view it is hard to distinguish whether this is intentional or a mistake. The point is that this change discovered actual errors in real code, so I am not so keen to revert this change even though it was unintentional.
On the other hand, such aliases will likely fail at runtime in most scenarios where it is an error quite soon. So the value of discovering them statically is not so big.
One possible way is to turn the type aliases into variables by giving them explicit types:
but then
Xcan't be used in annotations. I would like to see more input here before making a decision here.Quick fix for mypy 0.620 behavior
glyph commentedon Jul 16, 2018
I can see your point as far as this being a useful thing to check most of the time. And given that we're relying on private implementation details of typing I know it's my own responsibility to keep up with such changes :). Mainly what I'm looking for here is a non-horrible way forward that translates to something that will be close to a one-day public API. For example, I'm very curious what you mean by
what will make this the case?
(previous complaint
Type[Any]approach deleted, that was an error that was fixed in 0.620)glyph commentedon Jul 16, 2018
OK, now that I'm actually testing on the correct version:
still says "The type alias to Union is invalid in runtime context", which means any type I want to use in this way needs to be fully typed out twice.
glyph commentedon Jul 16, 2018
Is this a workable way to express this for the time being?
JelleZijlstra commentedon Jul 16, 2018
What if you do
x: Type[Any] = Union[int, str]?ilevkivskyi commentedon Jul 17, 2018
After a discussion with @JukkaL I think it is OK to allow the original example. This is however relatively low priority since there are workarounds like using
Type[Any]and/or# type: ignoreand/orif TYPE_CHECKING: ....15 remaining items
bwo commentedon Aug 6, 2019
More basically, if either of these works, shouldn't both?
We have codegen that creates functions that return
Union[…](for generative testing purposes). I suspect this is similar to the use @glyph has.Tishka17 commentedon Sep 8, 2019
Hello,
I'm working on library which helps to create dataclass instances from dict (a bit like pydantic or marshmallow). The main idea is to have funciton like
parse(data: Any, type_: Type[T]) -> T. It analyses what actual type as provied and does parsing based on detected infomation.I am working on new feature
polymrophic parsingand the use case is just to callparse(data, Union[ClassA, ClassB]). It works ok, but mypy detects an errorThe type alias to Union is invalid in runtime context. It is very strange to me that i cannot provide such a type explicitely, as at a same time i can detect it from annotations (and i do it for dataclass fields)Minimal exmaple is:
Some code from my library (reagento/adaptix@adc6f53)
What can i do with this?
ilevkivskyi commentedon Sep 9, 2019
@Tishka17 The simplest way is to
# type: ignorethis for now and wait for the issue to be resolved.Tishka17 commentedon Sep 17, 2019
Any ideas when it can be fixed?
ilevkivskyi commentedon Sep 17, 2019
As soon as someone submits a PR (i.e. no estimate).
wsanchez commentedon Oct 28, 2019
Any chance we can give this message its own error code instead of
[misc]?JukkaL commentedon Oct 28, 2019
Can you explain your use where this would be helpful?
wsanchez commentedon Oct 29, 2019
Well
[misc]lumps a lot of things into one bucket, which sort of defeats the point of having error codes.If you look at this diff: https://github.com/twisted/klein/pull/301/files, you'll see I added a ton of
#typedef ignore[misc]in the code, and I'd much rather have simply disable this warning globally in the config file, but I don't want to disable everything associated with[misc].This is due to a hack @glyph added here to help
mypyassociate Zope interfaces with the classes that implement them.chadrik commentedon Oct 29, 2019
@JukkaL IIRC, there were plans to be able to configure which error codes to ignore -- globally and per module -- so further classification of errors in the "misc" bucket will become even more significant after that feature arrives, since ignoring the entire "misc" error code would be ill advised.
There are a handful of errors like this one that fall into the "you used a type object incorrectly at runtime" grouping, which could perhaps share the same error code.
wsanchez commentedon Oct 29, 2019
@chadrik Heh I assumed that feature already existed. :-)
Allow type aliases in runtime context (#8779)