is this a valid import sequence ?

[Steven D'Aprano]

On Sat, 23 Jun 2007 17:51:17 -0700, Alex Martelli wrote:

> Steven D'Aprano <steve at REMOVE.THIS.cybersource.com.au> wrote:
> 
>> On Sat, 23 Jun 2007 11:03:03 -0700, Scott David Daniels wrote:
>> 
>> > The global statement in Write_LCD_Data is completely unnecessary.  The
>> > only time you need "global" is if you want to reassociate the global
>> > name to another object (such as LCD = LCD + 1 or whatever).
>> 
>> That's technically true, but declaring it with global makes the code
>> self-documenting and therefore easier to read.
>> 
>> It's never _wrong_ to use the global statement, even if it is strictly
>> unnecessary for the Python compiler.
> 
> So, repeat that global statement ninetyseven times -- that's not
> "wrong", either, in exactly the same sense in which it's not "wrong" to
> have it once -- the Python compiler will not complain.  And by repeating
> it over and over you make it less likely that a reader could miss it, so
> it's even more "self-documenting" and "easier to read", right?

No, repeating it ninety-seven times doesn't make it easier to read, it
makes it *harder* to read, and I'm sure I don't need to explain why.


> "Perfection is reached, not when there is no longer anything to
> add, but when there is no longer anything to take away", as Antoine de
> Saint-Exupery wrote.

That's debatable. Why does Python have decorators when there was already a
perfectly usable syntax for setting a method to function(method)? And
let's not even mention x += 1 etc.


> Since that global statement is utterly useless
> (it's impossible to read and understand any substantial amount of Python
> code without realizing that accessing a variable not locally assigned
> means you're accessing a global, so the "self-documenting" character
> claimed for that redundancy is quite fallacious),

Sure, in the *specific* example given, the body of the function was so
short that it would be a pretty poor developer who didn't know it was a
global.

But in a more substantial function, one using lots of variables, it might
not be clear which were global and which weren't unless you studied the
code, line-by-line.


> it IS perfectly
> suitable to take away, and so it's at least a serious imperfection.  It
> violates Occam's Razor, by multiplying entities (specifically
> statements) without necessity.  It's just about as bad as sticking a
> semicolon at the end of every statement (to make it "self-documenting"
> that the statement ends there), parentheses around the conditions in if
> and while statements and the argument in return statements (to make it
> "self-documenting" where those expressions start and end), and a few
> other less common ways to waste pixels, screen space, readers' attention
> spans, and everybody's time.

I'm not going to defend *any* of those practices. But I don't think
explicitly stating that a name is global, even when strictly unnecessary,
is in the same category. In practice, I wouldn't do so for a function that
was as short as the one the Original Poster used.

But consider also something like this:

def func(): 
    x, y = 1, 2
    z = x + y
    # lots more code doing many things here
    # some of which involve w
    return z + w

Let's pretend that there is sufficient code in there that it isn't obvious
at a glance that w is a global, okay?

There's a off-by-one error in the code, which we fix:

def func():
    x, y = 1, 2
    z = x + y
    # lots more code doing many things here
    # some of which involve w
    w = w + 1
    return z + w

"UnboundLocalError". Oops.


Now, I cheerfully admit that this scenario is contrived. Some people might
even argue that it is good for newbies to run into this error sooner
rather than later, but for those who don't think so, defensively inserting
a global statement might help prevent the issue from coming up.

I'm a big believer in letting newbies walk before running. I'd rather see
beginner programmers over-use global than under-use it. You're welcome to
disagree, but since UnboundLocalError seems to be one of the more
perplexing errors newbies suffer from, I think it is better for them to
avoid it until they've got a little more experience.


-- 
Steven.