Since Guido has explained local variables, I'll mention the
other reason for putting things into functions ( which Tim
has touched upon a bit in his post ): Python happens to be
a pretty good language w.r.t. code reuse and packaging things
up into classes or functions tends to make them more reusable -
especially in interactive use.
The __name__ of the module ( if it is run as a script, it will
be the __main__ module, otherwise it will be the name it is imported
by ) and the value of sys.argv - especially whether sys.argv[0] is
'' or '-c' gives you infomation about the context in which the
module is used or imported.
So typically, I'm in the habit of:
If I'm writing a stand-alone script meant to be run by itself,
If there are useful functions inside that could be reused, I make
them available to be imported.
If I'm writing a submodule, I'll have it check whether it has been
run stand-alone or imported, and if stand-alone, I'll have it do
something sensible: sometimes this is actually a useful program -
sometimes it is there mostly as a test that the functions work.
In a handful of more complicated modules, I have gone as far as to
put in a full-scale regression test, so that when I make any mods,
it is easy to test each module before they are integrated.
[ And, for Tim's "concrete" benefit: my first interest at mucking
about at module's __dict__'s and functions internals came up in
the context of experiments at trying to automate regression testing,
so that when I added a new function, it automatically got tested. ]
So in my case, wrapping it up in a function had little to do with
optimizing the code, and more to do with optimizing the use of the
code. If I was to go back and hack it it any more, I would probably
try to turn it into a class definition, with a printed string
representation, and methods to make it look like a sequence of
named fields, rather than a function that prints some output.
This class would suggest some other uses -
a 'kill by name' command would be convenient. 'kill.py prog' would
send a kill signal to *MY* instance of 'prog' - maybe with a
status printout and an "are you sure" prompt.
[ Gee - I started to describe it 'cause I didn't have time to WRITE
it, but it's starting to get more tempting to try to make time.
The last time I remember having a big "my version of" contest was
long ago with du-tree's ! ]
> By the way, thanks for all the responses guys.
> This way of learning a language is a lot better
> than my FORTRAN 101 course way back in '81.
Donald Knuth said there are two good ways to learn programming:
reading programs and writing programs.
( and I assume he would say the the BEST way is a mixture of both,
with a little editorial comment and criticism thrown it. )
I actually LIKE the abuse I get from Tim and Guido and others.
More than half the time they are objectively right. The rest
serves to illustrate just how differently different minds think!
> Course a sun workstation beats the hell out of cardpunch.
But nothing beats the intimacy of binary loading with PDP11 toggle
switches! ( How did we get into alt.folklore.computers? )
However, now that I'm using IBM RS/6000's, I'm growing partial to
'deadbeef' !
- Steve Majewski (804-982-0831) <sdm7g@Virginia.EDU>
- UVA Department of Molecular Physiology and Biological Physics