[issue41370] PEP 585 and ForwardRef

Guido van Rossum added the comment: New changeset b465b606049f6f7dd0711cb031fdaa251818741a by Niklas Rosenstein in branch 'main': bpo-41370: Evaluate strings as forward refs in PEP 585 generics (GH-30900) https://github.com/python/cpython/commit/b465b606049f6f7dd0711cb031fdaa251818741a

[issue41370] PEP 585 and ForwardRef

Niklas Rosenstein added the comment: I've started a pull request here: https://github.com/python/cpython/pull/30900 -- ___ Python tracker ___

[issue41370] PEP 585 and ForwardRef

Change by Niklas Rosenstein : -- pull_requests: +29079 pull_request: https://github.com/python/cpython/pull/30900 ___ Python tracker ___

[issue41370] PEP 585 and ForwardRef

Niklas Rosenstein added the comment: Interesting! Representing the entire type hint as a string is something I haven't thought about, but it makes sense that it works. It is my understanding that `get_type_hint()` already walks through the entire type hint recursively. If it weren't, it

[issue41370] PEP 585 and ForwardRef

Guido van Rossum added the comment: Here's a patch that doesn't do it right but illustrates the point: diff --git a/Lib/typing.py b/Lib/typing.py index 972b8ba24b..4616db60c3 100644 --- a/Lib/typing.py +++ b/Lib/typing.py @@ -1807,6 +1807,12 @@ def get_type_hints(obj, globalns=None,

[issue41370] PEP 585 and ForwardRef

Guido van Rossum added the comment: Ah, I see the issue. I stepped through get_type_hints() using pdb, and it does have a special case for when it encounters a string: it wraps it in a ForwardRef and proceeds from there:

[issue41370] PEP 585 and ForwardRef

Niklas Rosenstein added the comment: It was not my intention to sound passive agressive. Thanks for providing the context around the time PEP 585 was discussed. Frankly, I believe I have explained the problem quite well. But I would like to propose a solution. I can't judge in what

[issue41370] PEP 585 and ForwardRef

Change by Alex Waygood : -- nosy: +sobolevn ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue41370] PEP 585 and ForwardRef

Change by Alex Waygood : -- nosy: +AlexWaygood ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue41370] PEP 585 and ForwardRef

Guido van Rossum added the comment: When PEP 585 was discussed and implemented we did not expect people to care as much about runtime types as they did. I already explained that making list['Node'] incorporate a ForwardRef instance is unrealistic (we'd have to reimplement ForwardRef in C

[issue41370] PEP 585 and ForwardRef

Niklas Rosenstein added the comment: You're right, let me trim it down: In production we use `get_type_hints()` a lot, expecting it to resolve strings as forward references as per it's original API contract. However, PEP 585 generics parametrized with strings in Python 3.10 doesn't work

[issue41370] PEP 585 and ForwardRef

Change by Jelle Zijlstra : -- nosy: +Jelle Zijlstra ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue41370] PEP 585 and ForwardRef

Guido van Rossum added the comment: I asked for a brief example that explains your issue to me. Instead you sent me links to production code and patches to it. Sorry, but that doesn't help me understand your problem. Is there really no way that you can write a little story that goes along

[issue41370] PEP 585 and ForwardRef

Niklas Rosenstein added the comment: Guido, sorry for the late response on this. I have a work around, but it involves passing along my own "context" from which to resolve strings on the go as they are encountered while decomposing the type hint.

[issue41370] PEP 585 and ForwardRef

Guido van Rossum added the comment: Niklas, can you show a brief example showing the issue you're running into? Is it just that list["Node"].__args__ is just ("Node",), not (ForwardRef("Node"),)? Or is it more complex? -- ___ Python tracker

[issue41370] PEP 585 and ForwardRef

Niklas Rosenstein added the comment: I'm running into this issue right now. Can anyone provide a rationale as to why you think this is acceptable/expected behaviour? Do we expect developers to semi-rely on get_type_hints(), but than still having to manually resolve forward references in

[issue41370] PEP 585 and ForwardRef

Change by wyz23x2 : -- nosy: -wyz23x2 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue41370] PEP 585 and ForwardRef

miss-islington added the comment: New changeset d56bcf915b8d5a6afe4555cb6813c8210824e751 by Miss Islington (bot) in branch '3.9': [3.9] bpo-41370: Add note about ForwardRefs and PEP585 generic types in docs (GH-25183) (GH-25184)

[issue41370] PEP 585 and ForwardRef

Change by miss-islington : -- nosy: +miss-islington nosy_count: 8.0 -> 9.0 pull_requests: +23926 pull_request: https://github.com/python/cpython/pull/25184 ___ Python tracker

[issue41370] PEP 585 and ForwardRef

Guido van Rossum added the comment: New changeset 2b5913b4ee5852a28ca1509478f5582beb3aff7b by Ken Jin in branch 'master': bpo-41370: Add note about ForwardRefs and PEP585 generic types in docs (#25183) https://github.com/python/cpython/commit/2b5913b4ee5852a28ca1509478f5582beb3aff7b

[issue41370] PEP 585 and ForwardRef

Change by Ken Jin : -- nosy: +kj nosy_count: 7.0 -> 8.0 pull_requests: +23925 pull_request: https://github.com/python/cpython/pull/25183 ___ Python tracker ___

[issue41370] PEP 585 and ForwardRef

Change by wyz23x2 : -- pull_requests: -21248 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue41370] PEP 585 and ForwardRef

Change by wyz23x2 : -- pull_requests: +21248 pull_request: https://github.com/python/cpython/pull/22186 ___ Python tracker ___ ___

[issue41370] PEP 585 and ForwardRef

Change by wyz23x2 : -- pull_requests: -21247 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue41370] PEP 585 and ForwardRef

Change by wyz23x2 : -- pull_requests: +21247 pull_request: https://github.com/python/cpython/pull/22186 ___ Python tracker ___ ___

[issue41370] PEP 585 and ForwardRef

Change by wyz23x2 : -- pull_requests: -21245 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue41370] PEP 585 and ForwardRef

Change by wyz23x2 : -- keywords: +patch nosy: +wyz23x2 nosy_count: 6.0 -> 7.0 pull_requests: +21245 stage: -> patch review pull_request: https://github.com/python/cpython/pull/22186 ___ Python tracker

[issue41370] PEP 585 and ForwardRef

Change by STINNER Victor : -- nosy: -vstinner ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue41370] PEP 585 and ForwardRef

Guido van Rossum added the comment: Hm, recursive type aliases are an interesting issue. We may be able to do better there for 3.10, even if we can't fix it for 3.9 (or at least not for 3.9.0). But in the meantime maybe you can come up with a PR that adds a note to the typing docs in 3.10

[issue41370] PEP 585 and ForwardRef

Joseph Perez added the comment: However, PEP 563 will not solve the recursive type alias issue like `A = list["A"]` but this is a minor concern. -- ___ Python tracker ___

[issue41370] PEP 585 and ForwardRef

Guido van Rossum added the comment: I think mentioning this in the docs is the best we can do in 3.9, and for 3.10 the point will be moot. The next release is release candidate 1, so we're well past the point where we can implement new functionality. --

[issue41370] PEP 585 and ForwardRef

New submission from Joseph Perez : PEP 585 current implementation (3.10.0a0) differs from current Generic implementation about ForwardRef, as illustrated bellow: ```python from dataclasses import dataclass, field from typing import get_type_hints, List, ForwardRef @dataclass class Node: