On 2018-04-30 03:49, Tim Peters wrote:
[Soni L. <fakedme...@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'...
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Reply via email to