Message 390788 - Python tracker

➜

This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author	BTaskaya
Recipients	BTaskaya, gousaiyang, gvanrossum, lys.nikolaou, pablogsal, serhiy.storchaka
Date	2021-04-11.17:18:34
SpamBayes Score	-1.0
Marked as misclassified	Yes
Message-id	<1618161514.67.0.819080313809.issue42737@roundup.psfhosted.org>
In-reply-to

Content
> 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 OR). The thread raised some concerns regarding the verification of the lhs (the target), so the PR 23952 generates code for the lhs but omits the annotation part. > And FWIW changing how annotations are represented in the AST is out of scope for this issue. (There are tricky edge cases there too.) Agreed, it already has a separate issue.

> 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 OR).

The thread raised some concerns regarding the verification of the lhs (the target), so the PR 23952 generates code for the lhs but omits the annotation part.

> And FWIW changing how annotations are represented in the AST is out of scope for this issue. (There are tricky edge cases there too.)

Agreed, it already has a separate issue.

History
Date	User	Action	Args
2021-04-11 17:18:34	BTaskaya	set	recipients: + BTaskaya, gvanrossum, serhiy.storchaka, lys.nikolaou, pablogsal, gousaiyang
2021-04-11 17:18:34	BTaskaya	set	messageid: <1618161514.67.0.819080313809.issue42737@roundup.psfhosted.org>
2021-04-11 17:18:34	BTaskaya	link	issue42737 messages
2021-04-11 17:18:34	BTaskaya	create