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/2001-March/013366.html below:

[Python-Dev] violently deprecating exec without in (was: nested scopes. global: have I got it right?)

[Python-Dev] violently deprecating exec without in (was: nested scopes. global: have I got it right?) [Python-Dev] violently deprecating exec without in (was: nested scopes. global: have I got it right?)Jeremy Hylton jeremy@alum.mit.edu
Thu, 1 Mar 2001 20:31:28 -0500 (EST)
>>>>> "GvR" == Guido van Rossum <guido@digicool.com> writes:

  >> The nested scopes rules don't kick in until you've got one
  >> function nested in another.  The top-level namespace is treated
  >> differently that other function namespaces.  If a function is
  >> defined at the top-level then all its free variables are globals.
  >> As a result, the old rules still apply.

  GvR> This doesn't make sense.  If the free variables were truely
  GvR> considered globals, the reference to x would raise a NameError,
  GvR> because the exec doesn't define it at the global level -- it
  GvR> defines it at the local level.  So apparently you are
  GvR> generating LOAD_NAME instead of LOAD_GLOBAL for free variables
  GvR> in toplevel functions.  Oh well, this does the job!

Actually, I only generate LOAD_NAME for unoptimized, top-level
function namespaces.  These are exactly the old rules and I avoided
changing them for top-level functions, except when they contained a
nested function.

If we eliminate exec without "in," this is yet another problem that
goes away.

Jeremy



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