But that's a *separate problem*. Regexes can't assign directly either.
And we wouldn't want them to! (It's okay for a regex to have it's own
internal namespace, like named groups, but it shouldn't leak out into
the locals or globals.)
Extracting data from a string, like scanf, regexes, sed, awk, SNOBOL etc
sounds like a big win. Assignment should be a separate problem.
And at last I think I have thought of a use of dict unpacking I like. If
our scanf(pattern, target) function returns a dict of {name: value}
pairs, how do we apply it to locals?
target [, names] = **scanf(pattern, target)
where dict assignment matches assignment targets on the left with keys
in the dict. Acceptable target names are simple identifiers, dotted
names and subscripts:
spam, eggs.fried, cheese[0] = **{'cheese[0]': 3,
'spam': 1,
'eggs.fried': 2}
would do the obvious assignments. (I could live without the dotted names
and subscripts, if people don't like the additional complexity.)
Targets missing a key:value, or keys missing a target, would raise an
exception.
The bottom line here is that separation of concerns is a principle we
should follow. Text scanning and assignment are two distinct problems
and we should keep them distinct. This will allow us to pre-process the
pattern we want to match, and post-process the results of the scan, e.g.
spam, eggs, cheese = **(defaults | scanf(pattern, string))
We could have multiple scanners too, anything that returned a dict of
target names and values. We wouldn't need to build the scanner into the
interpreter, only the assignment syntax. The scanner itself is just a
function.
+1. Dict unpacking would be great, I'm not sure why we don't have it already. And I agree with the separation of concerns. If we had dict unpacking we could already do this kind of thing with named capture groups and groupdict.