lvalues and the lgb rule

[Michael P. Soulier]

On Fri, 6 Jul 2001 18:09:31 -0400, Tim Peters <tim.one at home.com> wrote:
> 
> 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).

    Granted, not dynamic in the sense that the underlying interpreter is
calling malloc(), but it acts as a double assignment/declaration. Not much
different than C++ really, except that you don't have to declare a type, it's
inferred by what you're assigning. Understood. 

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

    :) Everybody makes mistakes... 

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

    PyChecker? Ok, I'll look for that. Lets face it, mistakes happen. I mean,
Python's design has been in part to minimize typical errors found in other
languages. 
    For example, in Python I cannot do a standard Cism of assignment with
testing:

    if ((length = strlen(string)) > 2) 
        /* do something with string > 2 */

    This was removed in Python, preventing the classical error of assignment
when one intended to test

    Intent:

    if (x == 5)

    Accidental assignment

    if (x = 5)

    It seems to me that Python has been designed to avoid such errors, and yet
the omission of forced predeclaration, or at least warnings, seems like a
glaring omission to me. Just my opinion. 

    I'll give PyChecker a shot. 

> 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

:) Perhaps, but these idealistic ideas don't always work. They're not
exercised enough in the industry, true, but sometimes you can't afford the
overhead of all of those function calls. Granted, if you can afford Python,
you can probably afford the function calls. ;-)

    Thanks,

    Mike

-- 
Michael P. Soulier <msoulier at storm.ca> 
"With sufficient thrust, pigs fly just fine. However, this is not necessarily a
good idea. It is hard to be sure where they are going to land, and it could be
dangerous sitting under them as they fly overhead." -- RFC 1925