[Python-ideas] A "local" pseudo-function

MRAB python at mrabarnett.plus.com
Mon Apr 30 13:18:42 EDT 2018


On 2018-04-30 03:49, Tim Peters wrote:
> [Soni L. <fakedme+py at gmail.com>]
>> That ain't shadow. That is dynamic scoping.
> 
> I don't believe either term is technically accurate, but don't really care.
> 
> 
>> Shadowing is something different:
>>
>> def f():
>>     a = 42
>>     def g():
>>         print(a)
>>     local a:
>>         a = 43
>>         g()
>>     g()
>>
>> should print "42" both times, *if it's lexically scoped*.
> 
> Why?  The `local` statement, despite its name, and casual talk about
> it, isn't _intended_ to create a new scope in any technically accurate
> sense.  I think what it is intended to do has been adequately
> explained several times already.  The `a` in `a = 42` is intended to
> be exactly the same as the `a` in `a = 43`, changing nothing at all
> about Python's lexical scoping rules.  It is _the_ `a` local to `f`.
> If lexical scoping hasn't changed one whit (and it hasn't), the code
> _must_ print 43 first.  Same as if `local a:` were replaced by `if
> True:`.  `local` has no effect on a's value until the new "scope"
> _ends_, and never any effect at all on a's visibility (a's "scope").
> "local" or not, after `a = 43` there is no scope anywhere, neither
> lexical nor dynamic, in which `a` is still bound to 42.  _The_ value
> of `a` is 43 then, `local` or not.
> 
[snip]
I think it should be lexically scoped.

The purpose of 'local' would be to allow you to use a name that _might_ 
be used elsewhere.

The problem with a dynamic scope is that you might call some global 
function from within the local scope, but find that it's "not working 
correctly" because you've inadvertently shadowed a name that the 
function refers to.

Imagine, in a local scope, that you call a global function that calls 
'len', but you've shadowed 'len'...


More information about the Python-ideas mailing list