On Jun 12, 2015, at 11:25, Ron Adam <ron3200@gmail.com> wrote:
On 06/12/2015 01:21 PM, Ethan Furman wrote:
On 06/12/2015 08:14 AM, Stephen J. Turnbull wrote: Ethan Furman writes:
Likewise:
for val in some_iterator: use(val)
bar(val)
will shadow foo.val
Yes, I understand that. What I don't understand is your statement that you would like "if expr as val:" if it *doesn't* shadow.
Ah, I think I see your point. My use of the word "shadow" was in relation to the micro-scope and the previously existing name being shadowed and then un-shadowed when the micro-scope was destroyed. If we are at module-level (not class nor function) then there should be no shadowing, but a rebinding of the name. Even try/except blocks don't "shadow", but rebind and then delete the name used to catch the exception.
The problem can be turned around/over. Instead of specifying a name to be shadowed, the names to be shared can be specified. Then it translates to function with specified nonlocals.
I really like making it explicit. I'm not sure about the turning-it-around bit. That means inside a with-nonlocal block, things don't work the same as in any another block, and that won't be at all obvious. But even without that, the idea works; to make something nested-local, you write: with local b: for b in some_iterator: a = use(b) That leaves function-local as the default, and defines statement-local in a way that's as similar as possible to the other alternatives, environment-nonlocal and global; the only real difference is that it has a suite, which is pretty much implicit in the fact that it's defining something as local to the suite. Either way seems better than the quasi-magic scoping (both my version and Nick's took a couple paragraphs to explain...) caused by as expressions and/or clauses. And that's in addition to the advantages you suggested of not complicating the syntax and keeping separate concepts separate.
I like this better, but am still -0.5. I'd need to see some examples where it would be "worth it". It still feels like a solution looking for a problem to me.
Agreed. I think everyone (including myself) has put thought into this just because it's an interesting puzzle, not necessarily because the language needs it...