On Thu, Sep 17, 2020 at 09:16:46PM +0200, Alex Hall wrote: > On Thu, Sep 17, 2020 at 8:57 PM Brendan Barnwell <brenb...@brenbarn.net> > wrote: > > I don't like this at all. It looks like assigning to a literal, > > which > > is weird. > > > People keep saying this, but iterable unpacking looks like assigning to a > literal (a tuple or list literal) just as much.
Tuples and lists don't have literals, they have *displays*. You won't find them here: https://docs.python.org/3/reference/expressions.html#literals nor here: https://docs.python.org/3/reference/lexical_analysis.html#literals (although you will find f-strings, which I think is wrong, but I imagine that there will be a *huge* amount of pushback if I suggest we move f-strings to another section). Tuples are here: https://docs.python.org/3/reference/expressions.html#parenthesized-forms and list, set and dict displays immediately afterwards here: https://docs.python.org/3/reference/expressions.html#displays-for-lists-sets-and-dictionaries If there is anything that might justify the name "tuple (or list) literal" it would be a tuple with each item a literal: (1, "a", None) but certainly not one containing expressions or names: (spam+1, eggs(), aardvark.cheese) While we can use a tuple (or list) of *names* as an assignment target, we cannot use a tuple of literals as a target: (1, 2, 3) = (4, 5, 6) # SyntaxError > > Also, it hides the assignment target within a string of > > potentially unbounded length and complexity, which makes it difficult to > > reason about code because it's hard to see when variables are being > > assigned to. > > > It's really not. A decent IDE should already be able to automatically show > you assignments and usages of a variable - PyCharm does with one > Ctrl+click. A syntax highlighter that can handle f-strings will make the > assignments obvious at a glance. "A decent IDE" is not mandatory for writing Python code, and I would object strongly to making it so. We should be able to write code in Notepad, if no better alternative presents itself. The beauty of Python is that it is a relatively simple language that encourages code that is neither complex nor complicated. If syntax encourages complex, complicated code that requires an IDE to make sense of, that counts as a point against the syntax. That's not to deny that we can write obfuscated code in any language, but we shouldn't encourage it :-) Having said that, I don't actually agree that Brendan's point will be a major risk. This proposed feature is more or less the same as scanf, and I don't think people are in the habit of writing fifty thousand word scanf templates :-) And if they do, oh well, concenting adults apply. The advantage, as I see it, of special syntax is that it could implicity assign to the named targets. We don't actually need *f* strings for that, we don't even need strings: the {spam} and {eggs} was eaten by the {aarvark} = scanf(string) # automatically assigns to spam, eggs, aardvark could work, although it would be hard to match non-printable characters or special characters that need to be escaped, like newlines. It would also be difficult to do any sort of error handling: what if only a subset of targets match? -- Steve _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/J5T6GQWUCIFCCQTGBMDJWCNBPHEGM4JV/ Code of Conduct: http://python.org/psf/codeofconduct/
