good design & method calls

[Cameron Laird]

In article <586j41p6qmp93mafvql7uudtgn8r0nat3p at 4ax.com>,
Ron_Adam  <radam2 at tampabay.rr.com> wrote:
>On Tue, 29 Mar 2005 09:09:37 -0500, Charles Hartman
><charles.hartman at conncoll.edu> wrote:
>
>>I know the answer to this is going to be "It depends . . .", but I want 
>>to get my mind right. In Fowler's *Refactoring* I read: "Older 
>>languages carried an overhead in subroutine calls, which deterred 
>>people from small methods" (followed by the basic "Extract Method" 
>>advice). In Skip Montanaro's "Python Performance Tips" 
>>(http://manatee.mojam.com/~skip/python/fastpython.html) I read: ". . .  
>>use local variables wherever possible. If the above loop is cast as a 
>>function, append and upper become local variables. Python accesses 
>>local variables much more efficiently than global variables."
>>
>>These two pieces of advice imply opposite kinds of code revisions. 
>>Obviously they have different purposes, and both are right at different 
>>times. I wonder if anyone has some wisdom about how to think about when 
>>or how often to do which, how to balance them ultimately, and so on.
>>
>>Charles Hartman
>>Professor of English, Poet in Residence
>>the Scandroid is at: http://cherry.conncoll.edu/cohar/Programs
>>http://villex.blogspot.com
>
>
>It depends... ;)
>
>Converting small functions to inline, usually should  only be done in
>the inner most loops to optimize performance if it's needed.  Moving
>calculations out of those loops by doing them ahead of time is also
>good. 
>
>It's good practice in python to put all of your code in functions or
>class's even if it's a single main() function.  
>
>def main()
>  (program code)
>
>main()
>
>Then you avoid the slower globals unless you declare them with the
>global statement.
>
>If main, or any other functions, get too big or complex, split them up
>as needed. 
			.
			.
			.
I follow-up in part for the opportunity to address a Poet-in-residence.

I don't understand the claim that, "These two pieces of advice imply
opposite ..." actions.  In any case, I urge you to adopt the rule:
when in doubt, write a function (or method).  If you hesitate at all,
that's evidence that you'll eventually be thankful you invested the
effort explicitly to name a function (or method).

Also, I strongly recommend to you the *Python Cookbook* <URL:
http://www.oreilly.com/catalog/pythoncook2/ >.  Make sure you get the
second edition.  It will delight you more than you imagined a computing
book could.

I applaud Ron's advice to define a main().  As soon as possible, I also
want you to learn the "if __name__ == '__main__':", doctest, and pydoc
idioms; I suspect you'll find them all invaluable.