classification
Title: Syntax quirk with variable annotations
Type: behavior Stage: resolved
Components: Interpreter Core Versions: Python 3.8
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: Nosy List: gvanrossum, levkivskyi, pablogsal, rhettinger
Priority: low Keywords: patch, patch, patch

Created on 2019-01-24 05:45 by rhettinger, last changed 2019-06-04 00:44 by levkivskyi. This issue is now closed.

Pull Requests
URL Status Linked Edit
PR 11667 merged levkivskyi, 2019-01-24 13:22
PR 11667 merged levkivskyi, 2019-01-24 13:23
PR 11667 merged levkivskyi, 2019-01-24 13:23
PR 13757 merged levkivskyi, 2019-06-02 22:24
PR 13760 merged pablogsal, 2019-06-02 23:49
PR 13794 merged levkivskyi, 2019-06-04 00:44
Messages (8)
msg334280 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2019-01-24 05:45
Am not sure how much we care about this, but parenthesis around tuples stops being optional when there is a variable annotation. 

>>> from typing import Tuple
>>> t = 10, 'hello'                     # Parens not normally required
>>> t: Tuple[int, str] = (10, 'hello')  # Annotated allows parens
>>> t: Tuple[int, str] = 10, 'hello'    # Annotated w/o parens fails
SyntaxError: invalid syntax
msg334299 - (view) Author: Ivan Levkivskyi (levkivskyi) * (Python committer) Date: 2019-01-24 13:20
Good catch!

I think it was just overlooked rather than a conscious decision (unlike the left hand side, that generated lots of debates)

I will make a PR to allow everything that is allowed on r.h.s. of a normal assignment.
msg334335 - (view) Author: Ivan Levkivskyi (levkivskyi) * (Python committer) Date: 2019-01-25 01:39
New changeset 62c35a8a8ff5854ed470b1c16a7a14f3bb80368c by Ivan Levkivskyi in branch 'master':
bpo-35814: Allow same r.h.s. in annotated assignments as in normal ones (GH-11667)
https://github.com/python/cpython/commit/62c35a8a8ff5854ed470b1c16a7a14f3bb80368c
msg342355 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2019-05-13 16:27
I think PEP 526 does not clarify the intention here. Perhaps we could add a specific example? It currently shows:

  t: Tuple[int, ...] = (1, 2, 3)

We could just add this there:

  t: Tuple[int, ...] = 1, 2, 3
msg342356 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2019-05-13 16:28
(With a comment indicating that the second is only accepted in Python 3.8 and later.)
msg342869 - (view) Author: Ivan Levkivskyi (levkivskyi) * (Python committer) Date: 2019-05-19 20:57
Is PEP the best place for such updates? Maybe we can add a `versionchanged` note in https://docs.python.org/3/reference/simple_stmts.html#annotated-assignment-statements instead?
msg342908 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2019-05-20 14:52
> Is PEP the best place for such updates? Maybe we can add a `versionchanged` note in https://docs.python.org/3/reference/simple_stmts.html#annotated-assignment-statements instead?

We should definitely update the docs, with `versionchanged`.

But we should also update the PEP, because the reason this was changed was an interpretation issue in the PEP.  This is different from simply changing things in a later version because we've come up with a new idea or we've learned that something was a bad idea.

Now that the intention of the PEP has been clarified, the PEP itself ought to be updated with words expressing the clearer version; but because previously the intended syntax wasn't supported, it makes sense to also add a note there that this wasn't implemented correctly until 3.8.
msg344388 - (view) Author: Pablo Galindo Salgado (pablogsal) * (Python committer) Date: 2019-06-03 07:34
New changeset 8565f6b6db0fa9f65449b532a5056a98bad3dc37 by Pablo Galindo in branch 'master':
bpo-35814: Allow unpacking in r.h.s of annotated assignment expressions (GH-13760)
https://github.com/python/cpython/commit/8565f6b6db0fa9f65449b532a5056a98bad3dc37
History
Date User Action Args
2019-06-04 00:44:20levkivskyisetpull_requests: + pull_request13679
2019-06-03 07:34:31pablogsalsetnosy: + pablogsal
messages: + msg344388
2019-06-02 23:49:39pablogsalsetpull_requests: + pull_request13645
2019-06-02 22:24:25levkivskyisetpull_requests: + pull_request13638
2019-05-20 14:52:53gvanrossumsetkeywords: patch, patch, patch

messages: + msg342908
2019-05-19 20:57:31levkivskyisetkeywords: patch, patch, patch

messages: + msg342869
2019-05-13 16:28:31gvanrossumsetkeywords: patch, patch, patch

messages: + msg342356
2019-05-13 16:27:07gvanrossumsetkeywords: patch, patch, patch

messages: + msg342355
2019-01-25 02:48:43levkivskyisetkeywords: patch, patch, patch
status: open -> closed
stage: patch review -> resolved
resolution: fixed
versions: + Python 3.8, - Python 3.7
2019-01-25 01:39:25levkivskyisetmessages: + msg334335
2019-01-24 13:23:13levkivskyisetkeywords: + patch
stage: patch review
pull_requests: + pull_request11475
2019-01-24 13:23:05levkivskyisetkeywords: + patch
stage: (no value)
pull_requests: + pull_request11474
2019-01-24 13:22:58levkivskyisetkeywords: + patch
stage: (no value)
pull_requests: + pull_request11473
2019-01-24 13:20:56levkivskyisetmessages: + msg334299
2019-01-24 05:52:15xtreaksetnosy: + gvanrossum, levkivskyi
2019-01-24 05:45:39rhettingercreate