lvalues and the lgb rule

[Eric Hagemann]

>
> 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.
>

Is this true ?

Given a file with the following

print x

x=1

print x

The first print will fail with a 'NameError'.  It was my (perhaps) wrong
impression
that x "came into being" at the assignment (x=1)

I would think the variable is local to the code block once the assignement
has been executed

BTW whats the 'LGB' rule ?

Cheers

"Tim Peters" <tim.one at home.com> wrote in message
news:mailman.994457412.4660.python-list at python.org...
> [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
>
>