I never liked the nontestability of nested functions, and I also don't like the nontestability of these non-global semiglobalnonlocal variables. Real globals have the benefit that a test suite can check what happens to that variable as functions are called fairly easily. Here you have to test against my_func.__closure__[i].cell_contents for some i whose value depends on the order in which you created the variables and the order in which they're added to existing nonlocals (provided that isn't an implementation detail).
It keeps things simple. To be specific, when I read code I can "fold" (mentally or with the help of a code editor) the body of a def statement, knowing that I won't miss anything until the function is called.
+1. Yes.
I may be unduly worrying about this, but it feels to me that it lessens the overall tidiness of the language. I would much rather there was a way to initialise these "own" variables outside the body of the function.
There is. Have this "nonlocal assignment" as a magical decorator, or as syntax as part of the def statement. I'm not sure to what degree Nick's proposal is about the nonlocal syntax versus the nonlocal semantics. But you can keep the semantics (fast access to variables that are shared as global state) while changing the syntax fairly radically. Devin On Tue, Sep 27, 2011 at 6:24 PM, Arnaud Delobelle <arnodel@gmail.com> wrote:
On 27 September 2011 22:23, Guido van Rossum <guido@python.org> wrote:
On Tue, Sep 27, 2011 at 2:04 PM, Arnaud Delobelle <arnodel@gmail.com> wrote:
On 27 September 2011 21:38, Greg Ewing <greg.ewing@canterbury.ac.nz> wrote: [...]
As I remember, the idea foundered because it was thought too confusing to have an expression that was written inside the function but evaluated outside of it. If we're seriously considering the current proposal, presumably we've gotten over that? Or is it still a valid objection?
I have been reading this thread from the start and FWIW, it's something that I have been feeling uncomfortable about. I value the guarantee that no code in the body of a def statement is executed when the def statement itself is executed. This proposal would break this guarantee.
That seems a guarantee made up specifically to prevent this proposal.
I wouldn't do this :) I like new things.
What benefit do you see from it?
It keeps things simple. To be specific, when I read code I can "fold" (mentally or with the help of a code editor) the body of a def statement, knowing that I won't miss anything until the function is called. So the following won't raise:
[some code]
x = 42 def foo(): [I don't need to read the body] assert x == 42
But now def statements can have non-obvious side-effects. For example:
def spam_x(): global x x = "spam"
x = 42 def foo(): # Some body nonlocal y from spam_x() # More body assert x == 42
I may be unduly worrying about this, but it feels to me that it lessens the overall tidiness of the language. I would much rather there was a way to initialise these "own" variables outside the body of the function.
-- Arnaud _______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas