On Fri, Sep 18, 2020 at 4:56 AM Steven D'Aprano <st...@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.
_______________________________________________ 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/2O3TX6B4OKQJNHNCCU4MQMRLYKQK666I/ Code of Conduct: http://python.org/psf/codeofconduct/