stealing "var" from javascript

I know it's too late but as long as py3k will break everything, why not add explicit introduction of local variables? This is one place where Perl actually gets something right with "use strict;" and "my variable=...;" In particular there is a big conceptual difference between creating a new variable and changing a binding to an existing variable. You could make this difference explicit by saying # create local myvariable (error if exists) and assign value var myvariable=value; # rebind local myvariable (error if doesn't exist) myvariable = value; This would allow catching a lot of nameerrors at compile time, and also name mistakes which don't show up as nameerrors (like accidentally typing a variable name wrong in such a way that it doesn't fail the test cases, but only fails after deployment...). Any assignment with no associated "my" declaration would automatically be an error at compile time. As I say, I know it's too late. I also know it's probably not a new idea, but I couldn't locate it in a brief attempt. I also know that various python lint tools catch most name problems like the above... hmmm... I actually wouldn't mind the "my" keyword instead of "var" since it is shorter and probably less frequently used in existing code... (btw, "yield" broke every existing financial application :( ). Just a thought. -- Aaron Watters

Aaron Watters wrote:
[snip] I've worked with Perl more than I would have liked to, and IMO this is useful in Perl mainly because Perl code tends to grow into long functions and/or a lot of top-level code; better management of variables is essential simply because one needs more variables in a single scope to get things done. I was repeatedly surprised to find myself writing very long functions in Perl, unlike my style in every other language, and "use strict" really did catch such errors of mine many times. I've also recently worked a lot with JavaScript and the "var" thing is HORRIBLE!!! Ok, so after venting some steam, allow me to explain: JavaScript uses "var" for local variable declaration, and it has closures, and it has anonymous functions. Also, note that JavaScript's closures hold variables "by reference" rather than "by value". The result is that if you ever forget to write "var" in a function, you're very likely to end up overriding a variable from an outer scope, or various other problems. Such errors can be extremely hard to debug! Python's current scoping rules are confusing as well. But the lack of anonymous functions means you're more aware of the current scope (and outer scopes). And the "freezing" of variable values in closures makes using closers MUCH simpler and less bug-prone. Empirically, I don't think I've ever been bitten by this in Python, even though I've defined a lot of functions inside functions (inside functions...). - Tal

It would also help with local functions! def foo(): var x = 1 def bar(y): x += y * 2 bar(55)

Erick Tryzelaar wrote:
Indeed. Funny enough, it was a similar plea for a variable declaration keyword (mine, in fact) that was the final straw. Thus, after a bit of bike shedding and collision checking on the keyword spelling, "nonlocal" was born... Since the foremost use case has been handled, I expect a "var" proposal to go nowhere. The rationale, IIRC, is rather compression-oriented: in a language where only functions define inner scopes, it's far more likely that an assignment is meant to refer to the current scope than an outer scope. A declaration keyword is provided for the unlikely case, leaving the likely case declaration-free. In general, the more compressed your code is, the harder it is to detect encoding errors. In this case, Python's designers decided on compression over easy error detection. Neil

On 4/11/08, Neil Toronto <ntoronto@cs.byu.edu> wrote:
My experience is more the opposite. Yes, I have seen bugs from too-short identifiers, or wrongly assumed defaults. But I have seen far more errors from simple mistakes that would have been avoided if two parts of the code were visible at the same time. And I have seen plenty of bugs from things that people skipped over reading because they were skimming past boilerplate. And, of course, there are tons of (admittedly shallow) bugs that wouldn't be bugs in the first place if you didn't have to specify everything. (e.g., things fixed by explicit casts.) "var" by itself won't shove much off the screen. But changing from: """ def fn(a=4): x=5 ... """ to: """ def fn(a=4): var x var y var z x=5 ... """ is a big step in that direction. -jJ

El Monday, 14 de April de 2008 02:04:32 Jim Jewett escribió:
This looks kinda bloated to me. If I just want to do def f(b=2): # First assign x x=2*b # Now define function we'll use again later def fn(a=4): x=5 return a+x # and use x again. y = fn(x) Your idea would needlessly fill up lines here, because I'd have to declare x as local in the inner function (as I understand it). "When any function is defined, it's variables are local" is a nice and simple rule for me. (I'm sure there are some cases I miss, though... ) Best wishes, Arne -- Unpolitisch sein Heißt politisch sein Ohne es zu merken. - Arne Babenhauserheide ( http://draketo.de ) -- Weblog: http://blog.draketo.de -- Mein öffentlicher Schlüssel (PGP/GnuPG): http://draketo.de/inhalt/ich/pubkey.txt

On Thu, Apr 10, 2008 at 8:13 AM, Aaron Watters <aaron.watters@gmail.com> wrote:
If they don't support it already, the various lint tools could probably be extended to catch this. Just find out how similar the variable used in a function are, especially ones assigned only once and never used. -- Adam Olsen, aka Rhamphoryncus

Aaron Watters wrote:
[snip] I've worked with Perl more than I would have liked to, and IMO this is useful in Perl mainly because Perl code tends to grow into long functions and/or a lot of top-level code; better management of variables is essential simply because one needs more variables in a single scope to get things done. I was repeatedly surprised to find myself writing very long functions in Perl, unlike my style in every other language, and "use strict" really did catch such errors of mine many times. I've also recently worked a lot with JavaScript and the "var" thing is HORRIBLE!!! Ok, so after venting some steam, allow me to explain: JavaScript uses "var" for local variable declaration, and it has closures, and it has anonymous functions. Also, note that JavaScript's closures hold variables "by reference" rather than "by value". The result is that if you ever forget to write "var" in a function, you're very likely to end up overriding a variable from an outer scope, or various other problems. Such errors can be extremely hard to debug! Python's current scoping rules are confusing as well. But the lack of anonymous functions means you're more aware of the current scope (and outer scopes). And the "freezing" of variable values in closures makes using closers MUCH simpler and less bug-prone. Empirically, I don't think I've ever been bitten by this in Python, even though I've defined a lot of functions inside functions (inside functions...). - Tal

It would also help with local functions! def foo(): var x = 1 def bar(y): x += y * 2 bar(55)

Erick Tryzelaar wrote:
Indeed. Funny enough, it was a similar plea for a variable declaration keyword (mine, in fact) that was the final straw. Thus, after a bit of bike shedding and collision checking on the keyword spelling, "nonlocal" was born... Since the foremost use case has been handled, I expect a "var" proposal to go nowhere. The rationale, IIRC, is rather compression-oriented: in a language where only functions define inner scopes, it's far more likely that an assignment is meant to refer to the current scope than an outer scope. A declaration keyword is provided for the unlikely case, leaving the likely case declaration-free. In general, the more compressed your code is, the harder it is to detect encoding errors. In this case, Python's designers decided on compression over easy error detection. Neil

On 4/11/08, Neil Toronto <ntoronto@cs.byu.edu> wrote:
My experience is more the opposite. Yes, I have seen bugs from too-short identifiers, or wrongly assumed defaults. But I have seen far more errors from simple mistakes that would have been avoided if two parts of the code were visible at the same time. And I have seen plenty of bugs from things that people skipped over reading because they were skimming past boilerplate. And, of course, there are tons of (admittedly shallow) bugs that wouldn't be bugs in the first place if you didn't have to specify everything. (e.g., things fixed by explicit casts.) "var" by itself won't shove much off the screen. But changing from: """ def fn(a=4): x=5 ... """ to: """ def fn(a=4): var x var y var z x=5 ... """ is a big step in that direction. -jJ

El Monday, 14 de April de 2008 02:04:32 Jim Jewett escribió:
This looks kinda bloated to me. If I just want to do def f(b=2): # First assign x x=2*b # Now define function we'll use again later def fn(a=4): x=5 return a+x # and use x again. y = fn(x) Your idea would needlessly fill up lines here, because I'd have to declare x as local in the inner function (as I understand it). "When any function is defined, it's variables are local" is a nice and simple rule for me. (I'm sure there are some cases I miss, though... ) Best wishes, Arne -- Unpolitisch sein Heißt politisch sein Ohne es zu merken. - Arne Babenhauserheide ( http://draketo.de ) -- Weblog: http://blog.draketo.de -- Mein öffentlicher Schlüssel (PGP/GnuPG): http://draketo.de/inhalt/ich/pubkey.txt

On Thu, Apr 10, 2008 at 8:13 AM, Aaron Watters <aaron.watters@gmail.com> wrote:
If they don't support it already, the various lint tools could probably be extended to catch this. Just find out how similar the variable used in a function are, especially ones assigned only once and never used. -- Adam Olsen, aka Rhamphoryncus
participants (8)
-
Aaron Watters
-
Adam Olsen
-
Arne Babenhauserheide
-
Erick Tryzelaar
-
Jim Jewett
-
Mathias Panzenböck
-
Neil Toronto
-
Tal Einat