Yeah, we thought of that too, but it's harder than it looks to replicate all the behavior that typing.Union traditionally has. Ssome of that behavior is not interesting or useful -- but it's there, there are tests for it and people (presumably) depend on it, so we would have to replicate it. But we would prefer not to keep such baggage in the long term. Again, this is similar to how it went for GenericAlias. By leaving the typing.py implementation (largely) alone we preserve better backwards compatibility. The future is types.Union and types.GenericAlias, but it's going to be a long time before we have everyone over. This way people can explicitly decide when they're ready to switch from typing.Union[A, B] to A | B. --Guido On Wed, Jul 29, 2020 at 5:15 PM Nathaniel Smith <njs@pobox.com> wrote:
What about making typing.Union a re-export of types.Union?
On Wed, Jul 29, 2020, 15:26 Guido van Rossum <guido@python.org> wrote:
Because we don't want to have to import the full typing module into the C code. Philippe's prototype tried that and it was not a success.
We did this way for GenericAlias (the type returned by `list[int]`) as well.
--Guido
On Wed, Jul 29, 2020 at 3:06 PM Luciano Ramalho <luciano@ramalho.org> wrote:
Thanks for the update, Guido.
Why is it necessary to create `types.Union`? Why not enable `typing.Union` to play that role too?
Best,
Luciano
-- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-c...>