> What do you mean by this? Most languages I've worked with allow > variables to be initialized with arbitrary expressions, and a lot of > languages allow narrowly-scoped variables.
I'm talking about the *left* hand side of the assignment, not the right hand side. Initialization with arbitrary expression -- arbitrary expression is on the right. So, that's beside the point. Here are examples of languages that don't have a feature analogous to "augmented assignment target": * Java * C * Shell Examples of languages with limited use of destructuring: * Haskell * JavaScript * Ruby * Common Lisp Examples of languages with a superset of destructuring: * Prolog family of languages (in Prolog it's called "unification") What is the problem with Python's "augmented assignment target"? -- It is used in places where syntactically it is more common to introduce variables (and in languages with the limited use of destructuring, it's only possible to introduce variables in this context). For example, when destructuring an Array in JavaScript, the left-hand side is restricted syntactically to a very small subset of the language that, for example, excludes function application. Typically, it's not possible to use already defined variables in the left-hand side of the variable definition, even if destructuring assignment is possible. Prolog is the example of the opposite, where already defined variables are allowed on both sides of unification, but Prolog doesn't have function application in the same sense Python has, so it's still OK. In general, in languages that aren't like Prolog, conceptually, it's possible to either *define* variables (with optional initialization) or to *reuse* them (in the context of assignment that usually looks similar to initialization), but not both. The fact that in Python you can do both in the same place is surprising, eg. in the context of loops. Any language that distinguishes between expressions and statements would have conceptual difficulties with allowing a mix in the same context. Typically, variable introduction is a statement in such languages (as is the case in Python), so using an expression in the same place as a variable introduction is strange. To make this shorter, Python allows: for <statement> in ... : ... and for <expression> in ... : ... which is unexpected, especially since the first form is a lot more popular. Because the limited subset of expressions is desirable in this context, many languages try to "cram" it into this box. C, after some standard iterations caved in and allowed statements in the initialization component of the for loop (but only variable declaration statements), for example. Other languages like JavaScript developed a special subset of language for the purpose of describing the relationship between multiple components of the object being assigned as variables. In every case, from the language development perspective, this looks clumsy and unnecessary, as it is usually easy to write programs that are exactly equivalent but don't require such workarounds. But, in practice, programmers want to save a few keystrokes, and this pushes the language authors to add such "features". Python is furthermore unique in how the workaround creates a lot of opportunities for abuse. > The Python term, at least colloquially, is "tuple unpacking." Well, why use colloquialism if there's a language specification? Also, there weren't any tuples used in my example, at least not explicitly (i could've been a tuple, but that wasn't specified). -- https://mail.python.org/mailman/listinfo/python-list
