This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author xuancong84
Recipients xuancong84
Date 2021-05-04.05:05:15
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1620104716.88.0.704120170613.issue44028@roundup.psfhosted.org>
In-reply-to
Content
In general, the ability to update local variables is very important and it simplifies life tremendously. For example, in machine learning, it allows saving/loading arbitrary-format datasets and arbitrary-structure neural networks (NN) using a single line of code. In computer games, no matter how many complex data structures are there, saving and loading can be done in a single line.

Imagine you are game developer or a deep neural network (DNN) researcher, if all local variables are serializable, then no matter how complicated your game or your DNN structure is, saving the entire game or DNN (to STDOUT) can be simply put into one line as `print(locals())`, and loading the entire game or DNN (from STDIN) can be simply put into one line as `locals().update(eval(sys.stdin.read()))`.

Currently, `globals().update(...)` takes immediate effect but `locals().update(...)` does not work because Python documentation says:

> The default locals act as described for function locals() below:
> modifications to the default locals dictionary should not be
> attempted. Pass an explicit locals dictionary if you need to see
> effects of the code on locals after function exec() returns.

Why they design Python in such way is because of optimization and conforming the `exec` statement into a function:

> To modify the locals of a function on the fly is not possible without
> several consequences: normally, function locals are not stored in a
> dictionary, but an array, whose indices are determined at compile time
> from the known locales. This collides at least with new locals added
> by exec. The old exec statement circumvented this, because the
> compiler knew that if an exec without globals/locals args occurred in
> a function, that namespace would be "unoptimized", i.e. not using the
> locals array. Since exec() is now a normal function, the compiler does
> not know what "exec" may be bound to, and therefore can not treat is
> specially.

Since `global().update(...)` works, the following piece of code will work in root namespace (i.e., outside any function) because locals() is the same as globals() in root namespace:
```
locals().update({'a':3, 'b':4})
print(a, b)
```
But this will not work inside a function.

I have explored a few ways of hacking updating locals() on Python 3, it seems there is no way so far. The following piece of code seems to works:
```
def f1():
  sys._getframe(1).f_locals.update({'a':3, 'b':4})
  print(a, b)

f1()
```
However, that is because `sys._getframe(1)` is the root namespace, so `sys._getframe(1).f_locals.update()` is essentially `globals().update()`.

From the above Python developer documentation, I understand that in Python 2, local namespace lookup has 2 modes: optimized mode if there is no `exec` statement, un-optimized mode if there exists an `exec` statement. But in Python 3, `exec` becomes a function, so the compiler cannot determine which namespace optimization mode at compile time (because `exec` can be overridden or aliased into a different name). Therefore, Python 3 has only optimized namespace lookup. My suggestion is that whenever this optimized local namespace lookup fails, perform an un-optimized lookup (which will include locals()). This should solve the problem.

Do you have any other ideas or suggestions for doing this? Thanks!
History
Date User Action Args
2021-05-04 05:05:17xuancong84setrecipients: + xuancong84
2021-05-04 05:05:16xuancong84setmessageid: <1620104716.88.0.704120170613.issue44028@roundup.psfhosted.org>
2021-05-04 05:05:16xuancong84linkissue44028 messages
2021-05-04 05:05:15xuancong84create