On Fri, Sep 18, 2020 at 4:56 AM Steven D'Aprano <steve@pearwood.info> wrote:
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.