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/157764.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() semanticsNathaniel Smith njs at pobox.com
Tue May 28 22:27:59 EDT 2019
On Tue, May 28, 2019 at 6:48 PM Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
>
> 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.

Yeah, I made the classic mistake and forgot that my audience isn't as
immersed in this as I am :-). Throughout the email I'm assuming we're
going to adopt PEP 558's proposal about replacing f_locals with a new
kind of mutable view object, and then given that, asking what we
should do about locals().

-n

-- 
Nathaniel J. Smith -- https://vorpus.org
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