[Python-ideas] If branch merging

[Andrew Barnert]

On Jun 11, 2015, at 17:12, Ethan Furman <ethan at stoneleaf.us> wrote:
> 
>> On 06/11/2015 04:23 PM, Ron Adam wrote:
>> 
>> 
>>> On 06/11/2015 03:10 PM, Ethan Furman wrote:
>>>> On 06/11/2015 03:56 AM, Chris Angelico wrote:
>>>> 
>>>> while input("Spam? ") as spam:
>>>>     print(globals())
>>>>     break
>>>> 
>>>> Spam? yes
>>>> {... 'spam.0x7f2080260228': 'yes'...}
>>> 
>>> Having names not leak from listcomps and genexps is a good thing.
>> 
>> In a way this makes sense because you can think of them as a type of function literal.
>> 
>> 
>> 
>>> Having names not leak from if/else or while is confusing and irritating:
>>> there is no scope there, and at least 'while' should be similar to 'for'
>>> which also does a name binding and does /not/ unset it at the end.
>> 
>> Having a group of statement share a set of values is fairly easy to think about.
> 
> But that is not how Python works.  When you bind a name, that name stays until the scope is left (with one notable exception).

What Nick was proposing was to explicitly change the way Python works. And what Chris hacked up was (part of) what Nick proposed. So you're just pointing out that this change to the way Python works would be a change to the way Python works. Well, of course it would. The question is whether it would be a good change.

Nick's point was that they tried a similar change to implement comprehensions without needing to "fake it" with a hidden function, and it makes the implementation far too complex, so it doesn't even matter if it's a well-designed and desirable change. Of course it's also possible that it's not a desirable change (e.g., the current scoping rules are simple enough to keep things straight in your head while reading any function that isn't already too long to be a function, but more complex rules wouldn't be), or that it's possible desirable but not as designed (e.g., I still think Nick's idea of binding within the expression or the statement in a somewhat complex way is more confusing than just binding within the statement). But Chris's attempt to show that the implementation problems might be resolvable, and/or to give people a hack they can play with instead of having to guess, is still a reasonable response to Nick's point.

I agree with your implied point that a language with two kinds of locality, one nested by block and the other function-wide, is probably not as good a design as one with only the first kind (like C) or only the second (like Python), and that's even more true in a language with closures or implicit declarations (both of which Python has), so I think any design is going to be a mess (definitely including my own straw-man design, and Nick's, and what Chris's hack implements). But it's certainly a _possible_ design, and there's nothing about Python 3.5 that means it would be impossible or backward-incompatible (as opposed to just a bad idea) to have such a design for Python 3.6.