You might want to check out this thread in which I proposed something similar (and got similar objections):
http://mail.python.org/pipermail/python-dev/2006-July/066978.html Neil Toronto wrote: > As long as patches are flying willy-nilly and we're just kicking around > ideas like puppies, I thought I'd offer one of my own. > > No, not a puppy. An idea. Of course, if it ends up beaten to death, I > might rather it were a puppy. My apologies if it's been discussed in > some other form. > > It occurs to me that some of Python's gotchas are due to the compiler > not being able to determine whether the user intends to *create* a > variable, or *modify* one. > > The "global" gotcha: > > x = 0 > def f(): > print x # 'local variable 'x' referenced before assignment' > x = 3 > > > The "read-only lexical scoping" gotcha: > > def f(): > x = 0 > def g(): > x = 3 # doesn't alter outer 'x' > > > And the "changing a writable property name is a very bad plan" gotcha. > This bit me severely when I was first learning Python. I changed an > attribute name from "x" to "value" in some Bayesian network code, and > spent hours trying to determine why it wasn't working anymore. Turns out > I missed a "node.x = " somewhere. Nowadays, I'd write a dummy property > named "x" that throws an exception, but that seems an extraordinarily > hackish thing to do to support an operation that happens a lot. > > A "var" keyword fixes them all. The "global" gotcha: > > x = 0 > def f(): > print x # no exception - prints "0" > x = 3 > > def g(): > print x # exception > var x = 3 > > > The read-only lexical scoping gotcha: > > def f(): > var x = 0 > def g(): > x = 3 # alters outer 'x' > > > And when the runtime encountered "node.x = " it would have complained > that the variable didn't exist. The __init__ method would look like this: > > def __init__(self, stuff): > var self.stuff = stuff > var self.x = 0 > # ... > > > If you don't like how it looks, we could call it "eric" instead: > > eric self.x = 0 > > > Of course, "var" isn't a swear word in any language (as far as I know), > but "eric" is heinously rude in Swahili. > > Essentially, "var" means "make a new entry in the dictionary." > > Some Zen arguments: > > Explicit is better than implicit (are you creating? are you modifying?) > Complex is worse than simple (it's slightly more complex), but complex > is better than complicated (which the scoping semantics are now) > > It also has nice duality with the "del" keyword. Same number of letters > and everything: > > var x = 0 > del x > > > If type annotations ever got into Py3k, they'd go in very naturally. > This might also enable some compiler optimizations. > > The biggest downside I can see is that it would break every scrap of > Python code ever written. > > Another puppy to kick around: If that's totally unacceptable, how about > making the default for assignment act on a variable in the outer scope > if one exists, and have "var" override? This would allow read/write > lexical scoping and put the "this is meant to be new in this scope" > decoration at the point of declaration. (I also think "this is meant to > be new" is much cleaner than "this is meant to be old," but that's just me.) > > Grovelingly, > Neil > > _______________________________________________ > Python-3000 mailing list > Python-3000@python.org > http://mail.python.org/mailman/listinfo/python-3000 > Unsubscribe: > http://mail.python.org/mailman/options/python-3000/talin%40acm.org > > > _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
