On Fri, Sep 18, 2020 at 4:32 AM Alexis Masson <a.masson...@ntymail.com> wrote:
>
> On Fri, Sep 18, 2020 at 2:13 AM Alexis Masson <a.masson...@ntymail.com> wrote:
>
> This, in addition with locals().update(_), feels much better to me.
> Furthermore, it would allow other string-like classes, such as bytes or
> bytearray, to use that feature.
>
> But locals().update() isn't a supported operation, except in the
> situation where locals() is globals(). So what you're suggesting would
> work fine in the REPL but not in any production usage.
>
> ChrisA
>
> That surprises me. I put a quick test to check :
>
> def f() :
> print(locals())
> locals().update(dict(a=3))
> print(locals())
>
> f()
>
> prints :
>
> ================= RESTART: ****/test.py ================
> {}
> {'a': 3}
> >>>
>
> So maybe the specs don't force it, but under the current implementation, it
> seems to work.
>
It isn't supported, which means that sometimes it'll appear to work,
but you can't depend on it. For instance:
>>> def f():
... print(locals())
... locals().update({"a": 3})
... print(a)
...
>>> f()
{}
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "<stdin>", line 4, in f
NameError: name 'a' is not defined
The only time you can safely mutate locals() is when you're at top
level and it's the same as globals().
Plus, assignment might not even affect locals(), and it'd be extremely
weird if your parse operation couldn't assign to something declared
global :)
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/BE3WPJ54JTRRRUT7SOT2H35E4BYNGLYC/
Code of Conduct: http://python.org/psf/codeofconduct/
