why a main() function?

[Marc 'BlackJack' Rintsch]

Re: why a main() function?

In <7xk63zhpln.fsf @ruckus.brouhah a.com>, Paul Rubin wrote:

"Diez B. Roggisch" <deets@nospam.w eb.dewrites:

Python stores local variables in an indexed array, but globals in a
dictionary. Looking things up by index is faster than looking them up by
name.

>>
>Interesting. How is the index computed? I would have assumed that locals()
>is somehow used, which is a dicht.

>
They're static indexes assigned at compile time.

Which BTW is the reason why ``locals()['answer'] = 42`` does not work
within functions. The dictionary isn't the dictionary that's used for
locals but a proxy just for read access.

Ciao,
Marc 'BlackJack' Rintsch

[Fredrik Lundh]

Re: why a main() function?

Diez B. Roggisch wrote:

Interesting. How is the index computed? I would have assumed that locals()
is somehow used, which is a dicht.
>
I can imagine enumerating left-hand-side names and trying to replace their
occurence with the index, falling back to the name if that is not
possible/the index isn't found. Does that come close?

yes, but there is no fallback: if a name inside a function is local or
not is decided once and for all by the compiler, using static analysis.
see:

http://pyref.infogami.com/naming-and-binding

</F>

[Steven Bethard]

Re: why a main() function?

Steve Holden wrote:

beliavsky@aol.c om wrote:

>I think I read a suggestion somewhere to wrap the code where a Python
>script starts in a main() function, so one has
>>
>def main():
> print "hi"
>>
>main()
>>
>instead of
>>
>print "hi"
>>
>What are the advantages of doing this?
>>

Guido van Rossum himself can tell you:
>
http://www.artima.com/forums/flat.js...06&thread=4829

Interesting. A lot of the suggestions he makes are unnecessary if you
use argparse_ or optparse, since they do much cleaner argument parsing
and error reporting.

I basically never write a main() function in the sense described here.
My code usually looks something like:

if __name__ == '__main__':
parser = _argparse.Argum entParser(...)
parser.add_argu ment(...)
...
arguments = parser.parse_ar gs()

function_that_a ctually_does_st uff(arguments.f oo,
arguments.bar,
arguments.baz)

So my ``if __name__ == '__main__'`` block does just enough argument
parsing to be able to call a real function.

... _argparse: http://argparse.python-hosting.com/

STeVe

[anton.list@gmail.com]

Re: why a main() function?

beliavsky@aol.c om wrote:

I think I read a suggestion somewhere to wrap the code where a Python
script starts in a main() function, so one has

<snip>

What are the advantages of doing this?

Others have stated all the good ones, so I'll state a slightly dumber
one for us part time amateur hackers :)

If you start off writing all your python module inside a main function
then as you chop your code up into other functions (refactoring), the
code inside main is already at the proper indentation level for the new
top level functions. No more indenting it one level further to suit
the functions indentation.

--
Cheers
Anton

[Duncan Booth]

Re: why a main() function?

anton.list@gmai l.com wrote:

beliavsky@aol.c om wrote:

>I think I read a suggestion somewhere to wrap the code where a Python
>script starts in a main() function, so one has

>
><snip>
>

>What are the advantages of doing this?

>
Others have stated all the good ones, so I'll state a slightly dumber
one for us part time amateur hackers :)
>
If you start off writing all your python module inside a main function
then as you chop your code up into other functions (refactoring), the
code inside main is already at the proper indentation level for the new
top level functions. No more indenting it one level further to suit
the functions indentation.
>

That is also true if you start by putting all the main code inside an 'if
__name__=="__ma in__":' block. Besides, how hard is it to select the code
and hit tab or whatever the 'indent region' command is in your editor?

FWIW, my scripts generally evolve through several stages.

So looking at one I wrote recently I see that it started with a few lines
at the outer level which quickly went inside a __name__=='__ma in__' block
(so I could prod functions in the script interactively). Then as it grew
larger the script moved into a main() function and some argument processing
appeared in the __main__ block (and all the support functions disappeared
into a separate module). Then I wanted some exception handling at the outer
level so now I have the __main__ block containing outer level exception
handling, and calling main() which does argument processing and calls
script() which contains the original script.

It may evolve further: main() is a bit too large at the moment, and I think
I want to move the original script into another module with a command line
argument to select between scripts. My point being that I don't have a hard
and fast rule: I do whatever seems to make the code read clearly at the
time.