Extract lines from file, add to new files

[Left Right]

> 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).