Hi. [As I imagined explicit syntax did not catch up and would require lot of discussions.] [GvR]

...

Another way is to use special rules (similar to those for class defs), e.g. having

<frag> y=3 def f(): exec "y=2" def g(): return y return g()

print f() </frag>

# print 3.

Is that confusing for users? maybe they will more naturally expect 2 as outcome (given nested scopes).

This seems the best compromise to me. It will lead to the least broken code, because this is the behavior that we had before nested scopes! It is also quite easy to implement given the current implementation, I believe.

Maybe we could introduce a warning rather than an error for this situation though, because even if this behavior is clearly documented, it will still be confusing to some, so it is better if we outlaw it in some future version.

Yes this can be easy to implement but more confusing situations can arise: <frag> y=3 def f(): y=9 exec "y=2" def g(): return y return y,g() print f() </frag> What should this print? the situation leads not to a canonical solution as class def scopes. or <frag> def f(): from foo import * def g(): return y return g() print f() </frag> [Mark Hammond]

...

This probably won't be a very popular suggestion, but how about pulling nested scopes (I assume they are at the root of the problem) until this can be solved cleanly?

Agreed. While I think nested scopes are kinda cool, I have lived without them, and really without missing them, for years. At the moment the cure appears worse then the symptoms in at least a few cases. If nothing else, it compromises the elegant simplicity of Python that drew me here in the first place!

Assuming that people really _do_ want this feature, IMO the bar should be raised so there are _zero_ backward compatibility issues. I don't say anything about pulling nested scopes (I don't think my opinion can change things in this respect) but I should insist that without explicit syntax IMO raising the bar has a too high impl cost (both performance and complexity) or creates confusion.

[Andrew Kuchling]

...

Assuming that people really _do_ want this feature, IMO the bar should be raised so there are _zero_ backward compatibility issues.

Even at the cost of additional implementation complexity? At the cost of having to learn "scopes are nested, unless you do these two things in which case they're not"?

Let's not waffle. If nested scopes are worth doing, they're worth breaking code. Either leave exec and from..import illegal, or back out nested scopes, or think of some better solution, but let's not introduce complicated backward compatibility hacks. IMO breaking code would be ok if we issue warnings today and implement nested scopes issuing errors tomorrow. But this is simply a statement about principles and raised impression.

IMO import * in an inner scope should end up being an error, not sure about 'exec's. We should hear Jeremy H. position and we will need a final BDFL statement. regards, Samuele Pedroni.