Skip to content

gh-131933: Document UnionType/Union merger in What's New #131941

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

Merged
merged 6 commits into from
Apr 4, 2025
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
53 changes: 53 additions & 0 deletions Doc/whatsnew/3.14.rst
Original file line number Diff line number Diff line change
Expand Up @@ -1075,6 +1075,54 @@ turtle
(Contributed by Marie Roald and Yngve Mardal Moe in :gh:`126350`.)


types
-----

* :class:`types.UnionType` is now an alias for :class:`typing.Union`.
See :ref:`below <whatsnew314-typing-union>` for more details.
(Contributed by Jelle Zijlstra in :gh:`105499`.)


typing
------

.. _whatsnew314-typing-union:

* :class:`types.UnionType` and :class:`typing.Union` are now aliases for each other,
meaning that both old-style unions (created with ``Union[int, str]``) and new-style
unions (``int | str``) now create instances of the same runtime type. This unifies
the behavior between the two syntaxes, but leads to some differences in behavior that
may affect users who introspect types at runtime:

- Both syntaxes for creating a union now produce the same string representation in
``repr()``. For example, ``repr(Union[int, str])``
is now ``"int | str"`` instead of ``"typing.Union[int, str]"``.
- Unions created using the old syntax are no longer cached. Previously, running
``Union[int, str]`` multiple times would return the same object
(``Union[int, str] is Union[int, str]`` would be ``True``), but now it will
return two different objects. Users should use ``==`` to compare unions for equality, not
``is``. New-style unions have never been cached this way.
This change could increase memory usage for some programs that use a large number of
unions created by subscripting ``typing.Union``. However, several factors offset this cost:
unions used in annotations are no longer evaluated by default in Python 3.14
because of :pep:`649`; an instance of :class:`types.UnionType` is
itself much smaller than the object returned by ``Union[]`` was on prior Python
versions; and removing the cache also saves some space. It is therefore
unlikely that this change will cause a significant increase in memory usage for most
users.
- Previously, old-style unions were implemented using the private class
``typing._UnionGenericAlias``. This class is no longer needed for the implementation,
but it has been retained for backward compatibility, with removal scheduled for Python
3.17. Users should use documented introspection helpers like :func:`typing.get_origin`
and :func:`typing.get_args` instead of relying on private implementation details.
- It is now possible to use :class:`typing.Union` itself in :func:`isinstance` checks.
For example, ``isinstance(int | str, typing.Union)`` will return ``True``; previously
this raised :exc:`TypeError`.
- The ``__args__`` attribute of :class:`typing.Union` objects is no longer writable.

(Contributed by Jelle Zijlstra in :gh:`105499`.)


unicodedata
-----------

Expand Down Expand Up @@ -1608,6 +1656,11 @@ Changes in the Python API
This temporary change affects other threads.
(Contributed by Serhiy Storchaka in :gh:`69998`.)

* :class:`types.UnionType` is now an alias for :class:`typing.Union`,
causing changes in some behaviors.
See :ref:`above <whatsnew314-typing-union>` for more details.
(Contributed by Jelle Zijlstra in :gh:`105499`.)


Build changes
=============
Expand Down
Loading