A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2019-May/157761.html below:

[Python-Dev] [PEP 558] thinking through locals() semantics

[Python-Dev] [PEP 558] thinking through locals() semantics [Python-Dev] [PEP 558] thinking through locals() semanticsGreg Ewing greg.ewing at canterbury.ac.nz
Tue May 28 21:45:41 EDT 2019
Nathaniel Smith wrote:
> - [proxy]: Simply return the .f_locals object, so in all contexts
> locals() returns a live mutable view of the actual environment:
> 
>   def locals():
>       return get_caller_frame().f_locals

Not sure I quite follow this --  as far as I can see, f_locals
currently has the same snapshot behaviour as locals().

I'm assuming you mean to change things so that locals() returns a
mutable view tracking the environment in both directions. That
sounds like a much better idea all round to me. No weird
shared-snapshot behaviour, and no need for anything to behave
differently when tracing.

If the change to the behaviour of exec() and eval() is a concern,
then perhaps there should be a new localsview() function that
returns a mutable view, with locals() redefined as dict(localsview()).

-- 
Greg
More information about the Python-Dev mailing list

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4