[Python-3000] Sky pie: a "var" keyword

Gary Stephenson garys at ihug.com.au
Mon Oct 9 11:34:26 CEST 2006


----- Original Message ----- 
From: "Neil Toronto" <ntoronto at cs.byu.edu>
To: <python-3000 at python.org>
Sent: Monday, October 09, 2006 6:04 PM
Subject: [Python-3000] Sky pie: a "var" keyword


> 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

Fwiw, (which is not very much, given that I've never been an active 
Pythonista), I strongly support this idea - most particularly for the 
"read-only lexical scoping gotcha", which is to my eye the ugliest by far of 
Python's warts.  I'd prefer it be called "local" though (not "var" and 
definitely not "eric"), and only apply to local variables of functions - and 
not to instance variables of objects (which are already (sort of) covered 
by the __slots__  thingy).

However, I'm sure the second last paragraph tells the story of why it ain't 
never gonna happen. I imagine it would need  a fork to a completely new 
language.   And I don't think the idea outlined in the last paragraph is 
worthy of support at all.

A pity though - it would greatly improve the Python Language imho,

gary




More information about the Python-3000 mailing list