[issue42737] PEP 563: drop annotations for complex assign targets

Batuhan Taskaya added the comment: Ah, seems like there is still one open PR. Keeping this up for that... -- resolution: postponed -> status: closed -> open ___ Python tracker __

[issue42737] PEP 563: drop annotations for complex assign targets

Change by Batuhan Taskaya : -- resolution: -> postponed stage: patch review -> resolved status: open -> closed ___ Python tracker ___ _

[issue42737] PEP 563: drop annotations for complex assign targets

Batuhan Taskaya added the comment: New changeset 8cc3cfa8afab1651c4f6e9ba43a7ab7f10f64c32 by Batuhan Taskaya in branch 'master': bpo-42737: annotations with complex targets no longer causes any runtime effects (GH-23952) https://github.com/python/cpython/commit/8cc3cfa8afab1651c4f6e9ba43a7ab

[issue42737] PEP 563: drop annotations for complex assign targets

Change by Saiyang Gou : -- pull_requests: +24229 pull_request: https://github.com/python/cpython/pull/25511 ___ Python tracker ___ _

[issue42737] PEP 563: drop annotations for complex assign targets

Batuhan Taskaya added the comment: > Hum, there seems to be an actual bug here: even with PEP 563, the annotations > for "complex targets" are evaluated. For example: Yes, that is what this issue is about. This bug only surfaced while doing other stuff and PEP 563 being the default > I thin

[issue42737] PEP 563: drop annotations for complex assign targets

Guido van Rossum added the comment: The same thing happens at the module level. However in functions all is well (because inside functions annotations are never evaluated, apparently). It may be as simple as the code forgetting to check the PEP 563 bit when generating code for complex annota

[issue42737] PEP 563: drop annotations for complex assign targets

Guido van Rossum added the comment: Hum, there seems to be an actual bug here: even with PEP 563, the annotations for "complex targets" are evaluated. For example: from __future__ import annotations class C: x.y: z.w a: b.c The relevant parts of the disassembly of the code for the cl

[issue42737] PEP 563: drop annotations for complex assign targets

Batuhan Taskaya added the comment: > Batuhan, can you summarize the argument from the thread? What do you think > yourself? Myself, I'm not sure either way, but it seems okay to remove the > remnant bytecode. I feel like we shouldn't generate code for these annotations at all, and only eval

[issue42737] PEP 563: drop annotations for complex assign targets

Guido van Rossum added the comment: Batuhan, can you summarize the argument from the thread? What do you think yourself? Myself, I'm not sure either way, but it seems okay to remove the remnant bytecode. -- ___ Python tracker

[issue42737] PEP 563: drop annotations for complex assign targets

Batuhan Taskaya added the comment: > I think I'd be okay if `foo[bar]: baz` and `foo.bar: baz` (etc.) didn't > generate any bytecode at all. Is that what you're proposing here? If so, and > assuming the code is reasonably straightforward, I'd say go ahead and make a > PR (and close the old O

[issue42737] PEP 563: drop annotations for complex assign targets

Guido van Rossum added the comment: Hm, reading the thread it's not 100% clear to me what you are proposing to do in your patch, since different people seem to have proposed different things. I think I'd be okay if `foo[bar]: baz` and `foo.bar: baz` (etc.) didn't generate any bytecode at all

[issue42737] PEP 563: drop annotations for complex assign targets

Batuhan Taskaya added the comment: If there is enough interest, I'd like to propose to this before the beta cut -- ___ Python tracker ___ _

[issue42737] PEP 563: drop annotations for complex assign targets

Saiyang Gou added the comment: I think we can just skip evaluating annotations for complex targets when in module or class scope (they are not stored anyway). The point of PEP 563 is to suppress any evaluation of annotations (regardless of position) at definition time, while type checkers ca

[issue42737] PEP 563: drop annotations for complex assign targets

Batuhan Taskaya added the comment: I think we should still evaluate the targets (even though the sole purpose of this is just having a hint, the yield example seems serious), will update my patch accordingly. -- ___ Python tracker

[issue42737] PEP 563: drop annotations for complex assign targets

Serhiy Storchaka added the comment: About the difference in behavior. Currently: >>> (1/0).numerator: int Traceback (most recent call last): File "", line 1, in ZeroDivisionError: division by zero >>> x[0]: int Traceback (most recent call last): File "", line 1, in NameError: name 'x' is

[issue42737] PEP 563: drop annotations for complex assign targets

Batuhan Taskaya added the comment: > Do we still need to represent annotation as a subtree in AST? Or make it just > a string? Possibly, we will just represent them as Constant()s. See issue 41967 -- ___ Python tracker

[issue42737] PEP 563: drop annotations for complex assign targets

Serhiy Storchaka added the comment: Do we still need to represent annotation as a subtree in AST? Or make it just a string? -- ___ Python tracker ___

[issue42737] PEP 563: drop annotations for complex assign targets

Guido van Rossum added the comment: Yeah, we're talking about a future here where `from __future__ import annotations` is always on. And that future is now. (3.10) -- ___ Python tracker

[issue42737] PEP 563: drop annotations for complex assign targets

Batuhan Taskaya added the comment: > It will still perform run-time check which was an initial intention. Well, at least from my personal perspective, I'd expect all annotations to behave like strings regardless of their targets. -- ___ Python tra

[issue42737] PEP 563: drop annotations for complex assign targets

Serhiy Storchaka added the comment: Alternatively it could be evaluated in global scope. All names are globals (non-global names do not work in MyPy in any case), yield and await are forbidden outside function. It will still perform run-time check which was an initial intention. --

[issue42737] PEP 563: drop annotations for complex assign targets

Change by Batuhan Taskaya : -- keywords: +patch pull_requests: +22799 stage: -> patch review pull_request: https://github.com/python/cpython/pull/23952 ___ Python tracker ___

[issue42737] PEP 563: drop annotations for complex assign targets

Guido van Rossum added the comment: So the distinction between simple and complex is to define what goes into `__annotations__`. As long as we don't disturb that I think it's fine not to evaluate anything. (There's also the effect on what's considered a local variable, inside functions.) --

[issue42737] PEP 563: drop annotations for complex assign targets

New submission from Batuhan Taskaya : PEP 526 classifies everything but simple, unparenthesized names (a.b, (a), a[b]) as complex targets. The way the we handle annotations for them right now is, doing literally nothing but evaluating every part of it (just pushing the name to the stack, and