lvalues and the lgb rule

[Tim Peters]

[Michael P. Soulier]
> ...
>     In Python, previously unused lvalues cause that variable to
> be dynamically declared.

This is a flawed mental model:  the local vs non-local distinction is made
at compile-time, by static inspection of the program text.  There's nothing
dynamic about that (in the absence of "import *" and "exec" abuses).

> x = 1 # if x did not previously exist, following the LGB rule, it is
>       # declared dynamically here

Not dynamic.  Just look at the code in an editor:  if a name is bound
anywhere within a code block, and isn't declared in a "global" stmt, then
that name is local throughout the entire code block.

>     Now, while this is great for scripting, it can cause major
> headaches with large programs if you're a bad typist.

I expect bad typists have lots of other problems writing code too <wink>.

> It can declare new variables accidentally, when you wanted to assign
> to an existing one...
>
> myvar = 5
> .
> .
> myver = othervar

A tool like PyChecker will detect that, in the example exactly as given,
"myvar" and "myver" are *both* unreferenced, and flag both lines with
warnings.

> ...so here my typo of myver instead of myvar dynamically creates
> myver instead of assigning othervar to myvar.

It caused the compiler to believe you have two local vars, myvar and myver;
it makes no difference which one comes first; space for both is allocated
(in a sense) at compile-time.

> It can also accidentally obscure globals.
>
>     So, while the simple answer would be, "don't do that", we all
> know that accidents happen. So, I was wondering if there is a way to
> force declarations of variables to catch this kind of thing.

Not in Python:  "global" is its only declaration statement.  Use PyChecker:

    http://sf.net/projects/pychecker/

> Is there, or is there anything in the works, to assign with very large
> programs?

The size of the program doesn't really matter; regardless of program size,
if you don't keep your individual functions and methods to well under a
screen of code almost all the time, you're going to have lots of problems
(in Python or any other language; it may even be worse in Python, because
indendation for grouping really doesn't work well when code blocks slobber
over screen pages; that's one of the clever pressures in Python *nudging*
you toward writing better code).

guido-can-lead-you-to-clarity-but-he-can't-stop-you-from-peeing-in-
    the-stream<wink>-ly y'rs  - tim