classification
Title: Disallow expressions like (a) = 42
Type: Stage: resolved
Components: Interpreter Core Versions: Python 3.8
process
Status: closed Resolution: not a bug
Dependencies: Superseder:
Assigned To: pablogsal Nosy List: benjamin.peterson, gvanrossum, mark.dickinson, pablogsal, serhiy.storchaka, skrah
Priority: normal Keywords: patch

Created on 2018-11-10 04:13 by pablogsal, last changed 2018-11-12 21:35 by pablogsal. This issue is now closed.

Pull Requests
URL Status Linked Edit
PR 10444 closed pablogsal, 2018-11-10 04:15
Messages (7)
msg329590 - (view) Author: Pablo Galindo Salgado (pablogsal) * (Python committer) Date: 2018-11-10 04:13
As commented on Issue33878, the fact that expressions like (x) = 42 are accepted is, in reality, an implementation detail and they should be disallowed.
msg329591 - (view) Author: Pablo Galindo Salgado (pablogsal) * (Python committer) Date: 2018-11-10 04:20
I am not sure if this is the cleanest/simplest implementation...if you think there is a better way to do this I am happy to change the Pull Request :)
msg329593 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2018-11-10 05:30
I could have sworn Benjamin showed a fix for this during the core-dev sprint in Seattle...
msg329596 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2018-11-10 06:04
Actually, `(a) = 42` doesn't contradict the grammar.

assignment_stmt ::=  (target_list "=")+ (starred_expression | yield_expression)
target_list     ::=  target ("," target)* [","]
target          ::=  identifier
                     | "(" [target_list] ")"
                     | "[" [target_list] "]"
                     | attributeref
                     | subscription
                     | slicing
                     | "*" target

So that if we decide to disallow such things, we should change the definition in the language reference.

I thought the code should be similar to the code added in issue34641. But maybe there is a way to simplify both code.
msg329644 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2018-11-10 20:56
Hm, I was thinking of https://github.com/python/cpython/pull/9212/, but
that's about keyword arg (where the interpreter incorrectly allowed
f((kw)=expr). But on thinking about it more I believe we should allow (a) =
(b), so there is no code change required. Sorry for the false alarm.
msg329731 - (view) Author: Stefan Krah (skrah) * (Python committer) Date: 2018-11-12 13:31
I just want to add one more voice for allowing the status quo:

C, OCaml, SML, Haskell allow the assignment, Ruby disallows it.

The ML family must allow it, since "let (x) = 10" is pattern matching
under the hood, and (10) = 10.

In C (gcc, clang at least, I didn't check the standard) it may be convenience.


Python's assignment unpacking is similar to pattern matching, so
while the construct is surprising at first, I think it's the right
thing to do.
msg329740 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2018-11-12 16:09
Let's close this already. It won't happen. Sorry for the noise.
History
Date User Action Args
2018-11-12 21:35:48pablogsalsetstatus: open -> closed
resolution: not a bug
stage: patch review -> resolved
2018-11-12 16:09:37gvanrossumsetmessages: + msg329740
2018-11-12 13:31:43skrahsetnosy: + skrah
messages: + msg329731
2018-11-11 08:31:01mark.dickinsonsetnosy: + mark.dickinson
2018-11-10 20:56:35gvanrossumsetmessages: + msg329644
2018-11-10 06:04:25serhiy.storchakasetnosy: + benjamin.peterson
messages: + msg329596
2018-11-10 05:30:26gvanrossumsetmessages: + msg329593
2018-11-10 04:20:13pablogsalsetmessages: + msg329591
2018-11-10 04:19:25pablogsalsetnosy: + gvanrossum, serhiy.storchaka
2018-11-10 04:15:13pablogsalsetkeywords: + patch
stage: patch review
pull_requests: + pull_request9718
2018-11-10 04:13:18pablogsalcreate