Interesting discussion! Very enlightening. But after all that I'm still unconvinced that the new concept should be tied to the nonlocal keyword. Nick's right that the *mechanism* for nonlocals and __class__ is the same, and the mechanism for the new concept might well be the same. And possibly a hypothetical other Python implementation could use the same mechanism to keep track of default argument values. Or not. But at a different level, nonlocal and the new concept are quite different, and the difference has to do with the scope of the name, not its lifetime (this was a very important insight in the discussion!). I think it is actually very telling that the syntax for nonlocal, __class__ and default argument values is so different: to most users, the lifetime is much less of an issue than the scope. Now, let's pretend the new feature is called "own". We'd write: def counter(): own x = 0 x += 1 return x If we had another function (say, defined in the same scope): def count_by_twos(): own x = 0 x += 2 return x the x in counter() and count_by_twos() are unrelated. This is different from the way nonlocal works (I don't have to type the example I hope :-). Also, nonlocal is illegal in a global function -- syntactically, it must be in a function that is nested inside another function. For all these reasons, sorry Nick, but I really don't think any syntax based on nonlocal will do it, even "nonlocal <var> from <expr>". I see two options open at this point. 1) Bikeshed until we've come up with the right keyword. I think that apart from the keyword the optimal syntax is entirely fixed; "<keyword> <variable> = <expression>" is the way to go. (I suppose we could argue about how to declare multiple variables this way.) I would be okay with using either "static" or "own" for the keyword. Personally, I don't really mind all the negative baggage that static has, but a Google code search for \bown\s= shows way fewer hits than for \bstatic\s= (both with lang:^python$ case:yes). 2) Give up, and keep using the default argument hack. You can protect your arguments from accidentally being overridden by using a "lone star" in the argument list (PEP 3102) and a __private naming convention. The lone star prevents accidental overriding when too many positional arguments are given. The __private provides sufficient protection against misguided attempts to provide a value for such "arguments", even if for functions outside a class it is purely psychological. (Note that someone who *really* wanted to mess with a cell's variable could also do it.) -- --Guido van Rossum (python.org/~guido)