[Tutor] Questions about Functions

[bob smith]

Thank you Jeff, Ike and Danny.  I appreciate all of your quick responses and 
great help.  I'm sure I'll be back with more questions soon.

Bob


>From: "Jeff Shannon" <jeff@ccvcorp.com>
>To: tutor@python.org
>CC: bob smith <bobsmith327@hotmail.com>
>Subject: Re: [Tutor] Questions about Functions
>Date: Tue, 18 Feb 2003 13:19:18 -0800
>
>
>bob smith wrote:
>
>>Hi. Im learning Python and like it very much so far, but I have some 
>>questions when it comes to functions.
>>
>>Question #1
>>--------------
>>Whats wrong with passing a variable to a function that receives it with 
>>the same name?
>
>
>The only problem here is that it's possible that you'll lose track of the 
>fact that they are, in fact, two separate variables. You might, for 
>instance, change 'value' in your function, and then be surprised by the 
>fact that the global 'value' is not updated. But if it's clear in your mind 
>that when you're inside a function, you're in a whole different world 
>(well, different namespace), then there's no problem. (At least, no problem 
>until someone *else* goes to modify your code and gets surprised by 
>this...) But this is strictly a programmer-psychology issue, and not a 
>technical issue.
>
>>Question #2
>>--------------
>>Is it considered bad programming to access (and only access) global 
>>variables in functions, thus treating them as global constants?
>
>
>The problem here is that functions (ideally) should be able to operate 
>identically in a variety of contexts, and thus functions should be as 
>self-contained as possible. If your function relies on global constants, 
>and then you have another module that needs the same function, you have to 
>ensure that all the same global constants are set up in that other module.
>
>>Since I cant assign a new value to CONSTANT in func(), does this mean 
>>that Python encourages the use of global constants used like this?
>
>
>You *can* actually assign a new value to CONSTANT -- except that it creates 
>a new local variable that shadows your global constant, with potentially 
>confusing results.
>
>>It seems like a good idea to me, (especially if CONSTANT is needed in 
>>other functions in the program) but you hear the mantra dont use global 
>>variables so much that Im not sure if this is considered poor 
>>programming.
>
>
>Here's the rub -- using constants like this *is* a very useful thing, and 
>sometimes it really is the best option. Certainly using global constants is 
>a lot less hazardous than using global "normal" variables, and as you say, 
>if the constant is needed in a wide variety of places, a global constant is 
>probably better than a dozen local constants (which would be a nightmare to 
>keep in sync if the value needs tweaked). In programs that are large enough 
>to have this issue, I'll usually create a separate constants.py that does 
>nothing but define these constants. Then, every other module that needs to 
>use the constants can 'import constants; print constants.CONSTANT' or 
>equivalent. This gives me the practical value of having global constants 
>available, but still keeps them (relatively) isolated in their own 
>playground.
>
>>Question #3
>>--------------
>>If you know your program is not going to be imported (only run as a 
>>stand-alone program) do you ever need to consider having this kind of 
>>thing:
>>
>>if __name__ == __main__: main()
>
>
>If you're absolutely positive that your script will never be used as a 
>module somewhere else, then this isn't necessary. The catch is that it 
>often happens that a function that you once thought would never be needed 
>elsewhere will suddenly become a quick solution to a new problem elsewhere, 
>and you'll find yourself wanting to import that "only ever stand-alone" 
>program.
>
>The other point here is that this convention supports a design practice. 
>When I'm writing a program, I mentally break the problem down into little 
>pieces, and then I start writing a series of functions (or a set of 
>classes) that'll solve each of those pieces. Once I have the low-level 
>problems solved, I start tying those bits together with higher-level 
>functions, until I have something like a main() function that solves the 
>whole problem. So the 'if __name__ == __main__:' convention fits well 
>with the way that I work. If I were to approach a problem with the thought 
>of *not* using this convention, then I'd be tempted to write a much more 
>linear program (as opposed to a small heirarchy of classes and functions). 
>This is fine for very small scripts, usually, but becomes increasingly 
>difficult to follow as the size of the program grows. And, of course, even 
>very small programs have a tendency to grow in size and complexity... so it 
>seems best to start off in the right direction to begin with.
>
>Hope this makes a few things more clear.
>
>Jeff Shannon
>Technician/Programmer
>Credit International
>
>
>
>_______________________________________________
>Tutor maillist  -  Tutor@python.org
>http://mail.python.org/mailman/listinfo/tutor


_________________________________________________________________
MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*.  
http://join.msn.com/?page=features/virus