On Fri, Oct 23, 2020 at 12:56 AM Paul Moore <p.f.mo...@gmail.com> wrote:
>
> On Thu, 22 Oct 2020 at 14:44, Chris Angelico <ros...@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
_______________________________________________
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/NJWVW7RVRHQILZERHYQMF63ARHGTDBMJ/
Code of Conduct: http://python.org/psf/codeofconduct/
