![](https://secure.gravatar.com/avatar/d67ab5d94c2fed8ab6b727b62dc1b213.jpg?s=120&d=mm&r=g)
On Fri, Oct 23, 2020 at 12:56 AM Paul Moore <p.f.moore@gmail.com> wrote:
On Thu, 22 Oct 2020 at 14:44, Chris Angelico <rosuav@gmail.com> wrote:
Returning a dict would be FAR less convenient for the most common cases, but as you say, it'd be the fallback for when you need dynamic parsing.
If you're that sure that direct assignment to locals would be a killer feature (I'm not, but you seem to be unimpressed by any scanning proposal that *doesn't* include it) maybe a better syntax proposal would be something that takes a dict (or more generally maybe a "namespace") and injects it into locals? That could be used by a scanner function, as well as any other library that wanted a "directly assign variables" interface. So rather than
f"{var1} {var2} {var3}" = target
we'd have
inject_vars parser("{var1} {var2} {var3}", target)
and people who don't like/want variable assignment can just use parser() as a normal function returning a dict.
The trouble with this is that there's no way to know, at compilation time, what names are being assigned to. I think that basically makes it a non-starter. It'd have to be something like JavaScript's destructuring syntax, where you explicitly name the variables you want to grab: const {var1, var2, var3} = target; but that would mean the same duplication of names that was the reason for f-strings on the RHS. I think this kind of thing might be useful, but it wouldn't be enough to make this feature work. ChrisA