[Python-Dev] Magic main functions

[Nick Coghlan]

Phillip J. Eby wrote:
> Perhaps this means that -m is premature?  I personally would rather wait 
> for 2.5 if it means we get a nice, future-proof "main" convention out of 
> the deal.  While -m would not then be "backward compatible" with 
> existing scripts, people could start changing scripts to match the 
> convention as soon as there was an accepted PEP.

I see the two issues as entirely orthogonal. A new main function idiom 
should not have to rely on the use of a particular command line switch 
(particularly since there is no way to 'switch off' the current idiom 
without significant changes to the interpreter).

If we were actually developing a new idiom, I would be thinking more 
along the following lines:

"After initial execution of the __main__ module in non-interactive mode 
(e.g. running a script supplied by filename or using -m), the 
interpreter looks for a function also called __main__ in the __main__ 
module's namespace. If such a function is found, it is executed by the 
interpreter as if the call __main__() had been appended to the end of 
the supplied script."

Existing scripts would continue to work as is, or else could be 
converted to use the new idiom by replacing the line "if __name__ == 
'__main__':" with the line "def __main__():"

Scripts that need to be backwards compatible can use the old idiom and 
include the following to mark themselves as definitely being usable as 
scripts:

   def __main__(): pass

Or else, they can be made compatible with older versions by adding the 
following snippet to the end:

   if __name__ == '__main__':
     import sys
     if sys.version_info[0:2] < [2, 5]:
        __main__()

About the only real practical (as opposed to aesthetic) advantage I see 
to such an idiom is that the question "Is this module useful as a 
script?" can easily be answered as "Yes" by looking for a __main__ 
function. (We can't really answer 'No' definitively, since a script may 
be using the existing idiom without using the 'def __main__(): pass' trick).

Although "def __main__():" could be easier to explain to beginners than 
the current approach. That might also be a slight benefit.

*stops to think for a bit*
Actually, while proofreading this, one other potential advantage occured 
to me - this might allow C extensions and the like to define __main__ 
functions, and so be usable as scripts via -m despite their non-script 
packaging. Although that seems like an awful lot of work for not much 
gain - it would presumably be easier to just distribute a package that 
included both the extension module and a 'launcher' Python script.

Anyway, regardless of whether a new main idiom is ever selected or not, 
I just don't see the link between that and being able to search for 
scripts using Python's module namespace instead of the OS filesystem's 
namespace.

Cheers,
Nick.