-
-
Notifications
You must be signed in to change notification settings - Fork 31.9k
Merge typing.Union
and types.UnionType
#105499
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
Comments
I put up a first implementation at #105511. Some thoughts on the details:
|
This broken an AST walker I had written for Python 3.9, after I upgraded all my |
Will this also fix the issue of i.e. class Foo:
def get_self(self) -> "Foo" | None:
pass
# Traceback (most recent call last):
# File "<stdin>", line 1, in <module>
# File "<stdin>", line 2, in Foo
# TypeError: unsupported operand type(s) for |: 'str' and 'NoneType'
from typing import Union
class Foo:
def get_self(self) -> Union["Foo", None]:
pass
# no issues |
@MarsCapone, no, but other changes in Python 3.14 (PEP-649) will fix that case. |
See also https://mypy.readthedocs.io/en/stable/runtime_troubles.html and |
Co-authored-by: Alex Waygood <[email protected]> Co-authored-by: Ken Jin <[email protected]> Co-authored-by: Carl Meyer <[email protected]>
The main issue: newish syntax for unions with `|` supported by Python 3.10 are of [type](https://docs.python.org/3.10/library/types.html#types.UnionType) `types.UnionType`, and didn't match `type(Union)`. There's a very recently [completed issue on CPython](python/cpython#105499) that will unify both (apparently for 3.14). See also this [MyPy warning](https://mypy.readthedocs.io/en/stable/runtime_troubles.html#future-annotations-import-pep-563) about evaluating type hints. Other issues: - Only unions of two values were properly handled for optional values; - Unions with more than two values and an optional one would only parse one of the values, dropping the others; - Some code lines were never true (like `isinstance(arg_json_schema["type"], list)`); The code is now simplified while handling new type annotation syntax and null/optional values.
The main issue: newish syntax for unions with `|` supported by Python 3.10 are of [type](https://docs.python.org/3.10/library/types.html#types.UnionType) `types.UnionType`, and didn't match `type(Union)`. There's a very recently [completed issue on CPython](python/cpython#105499) that will unify both (apparently for 3.14). See also this [MyPy warning](https://mypy.readthedocs.io/en/stable/runtime_troubles.html#future-annotations-import-pep-563) about evaluating type hints. Other issues: - Only unions of two values were properly handled for optional values; - Unions with more than two values and an optional one would only parse one of the values, dropping the others; - Some code lines were never true (like `isinstance(arg_json_schema["type"], list)`); The code is now simplified while handling new type annotation syntax and null/optional values.
The main issue: newish syntax for unions with `|` supported by Python 3.10 are of [type](https://docs.python.org/3.10/library/types.html#types.UnionType) `types.UnionType`, and didn't match `type(Union)`. There's a very recently [completed issue on CPython](python/cpython#105499) that will unify both (apparently for 3.14). See also this [MyPy warning](https://mypy.readthedocs.io/en/stable/runtime_troubles.html#future-annotations-import-pep-563) about evaluating type hints. Other issues: - Only unions of two values were properly handled for optional values; - Unions with more than two values and an optional one would only parse one of the values, dropping the others; - Some code lines were never true (like `isinstance(arg_json_schema["type"], list)`); The code is now simplified while handling new type annotation syntax and null/optional values.
## Description **Summary of changes**: The main problem: newish syntax for unions with `|` supported by Python 3.10 are of [type](https://docs.python.org/3.10/library/types.html#types.UnionType) `types.UnionType`, and didn't match `Union`. There's a very recently [completed issue on CPython](python/cpython#105499) that will unify both (apparently for 3.14). See also this [MyPy warning](https://mypy.readthedocs.io/en/stable/runtime_troubles.html#future-annotations-import-pep-563) about evaluating type hints. Other problems: - Only unions of two values were properly handled for optional values; - Unions with more than two values and an optional one would only parse one of the values, dropping the others; - Some code lines were never true (like `isinstance(arg_json_schema["type"], list)`); The code is now simplified while handling new type annotation syntax and null/optional values. Fixes #2441. - **Related issues**: I didn't find any. - **Motivation and context**: I was getting errors with a custom toolkit that uses the new type hinting syntax. - **Environment or dependencies**: None. - **Impact on metrics**: N/A. --- ## Type of change Please check the options that are relevant: - [x] Bug fix (non-breaking change which fixes an issue) - [ ] New feature (non-breaking change which adds functionality) - [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected) - [ ] Model update (Addition or modification of models) - [ ] Other (please describe): --- ## Checklist - [x] Adherence to standards: Code complies with Agno’s style guidelines and best practices. - [x] Formatting and validation: You have run `./scripts/format.sh` and `./scripts/validate.sh` to ensure code is formatted and linted. - [x] Self-review completed: A thorough review has been performed by the contributor(s). - [x] Documentation: Docstrings and comments have been added or updated for any complex logic. - [ ] Examples and guides: Relevant cookbook examples have been included or updated (if applicable). - [x] Tested in a clean environment: Changes have been tested in a clean environment to confirm expected behavior. - [ ] Tests (optional): Tests have been added or updated to cover any new or changed functionality. --- ## Additional Notes Linked in the description. --------- Co-authored-by: Dirk Brand <[email protected]>
`_UnionGenericAlias` is no longer used to construct unions, see python/cpython#105499.
`_UnionGenericAlias` is no longer used to construct unions and `UnionType` is an alias of `Union`, see python/cpython#105499.
A bunch of other warnings in typing.py were already deferred, but I added a few non-lazy ones.
A bunch of other warnings in typing.py were already deferred, but I added a few non-lazy ones.
Co-authored-by: Alex Waygood <[email protected]> Co-authored-by: Ken Jin <[email protected]> Co-authored-by: Carl Meyer <[email protected]>
Leftover from python#105511 I believe. GitHub code search found no usages other than copies of typing.py and lists of stdlib functions.
A bunch of other warnings in typing.py were already deferred, but I added a few non-lazy ones.
Currently, unions created through
typing.Union[A, B]
and through the PEP-604 syntaxA | B
are at runtime instances of completely different types, and they differ in exactly what elements they accept. This is confusing and makes it harder for users to detect unions at runtime.I propose to proceed in two steps:
typing.Union
an alias fortypes.UnionType
and make it sotypes.UnionType[A, B]
works, accepting the same typesUnion
accepts now.|
operator accepts to accept more types that are commonly used in unions.Linked PRs
The text was updated successfully, but these errors were encountered: