[Python-ideas] If branch merging

[Andrew Barnert]

On Jun 12, 2015, at 11:25, Ron Adam <ron3200 at 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...