[Python-Dev] (name := expression) doesn't fit the narrative of PEP 20
Steven D'Aprano
steve at pearwood.info
Thu Apr 26 03:29:17 EDT 2018
More information about the Python-Dev mailing list
Thu Apr 26 03:29:17 EDT 2018
- Previous message (by thread): [Python-Dev] (name := expression) doesn't fit the narrative of PEP 20
- Next message (by thread): [Python-Dev] (name := expression) doesn't fit the narrative of PEP 20
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Thu, Apr 26, 2018 at 07:16:28PM +1200, Greg Ewing wrote: > Tim Peters wrote: > >As a statement in a program (as opposed to typed at a shell), > >"a := 3" has the unnecessary (in that context) property of returning > >(and discarding 3), so it's better style to use "a = 3" in that > >context. > > That seems like a post-hoc justification. If := were the one > and only assignment symbol, the compiler could easily optimise > away the extra DUP_TOP or whatever is involved. Its still bad form to rely on compiler-dependent optimizations which aren't part of the language specification. And to steal an earlier idea from Tim, it is especially unfortunate if you copy data := sorted(huge_list_with_billions_of_items) from a program and paste it into your REPL, then can't type again for an hour or two. The longer I think about this, the more I am convinced that having two forms of assignment, one a statement with no return value and the other an expression with a return value, is a feature, not a wart or bug. Yes, it does add some complexity to the language, but it is *useful* complexity. If all complexity was bad, we'd still be programming by flicking toggle switches. -- Steve
- Previous message (by thread): [Python-Dev] (name := expression) doesn't fit the narrative of PEP 20
- Next message (by thread): [Python-Dev] (name := expression) doesn't fit the narrative of PEP 20
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Python-Dev mailing list