Issue1418

Test program:

if __name__ == '__main__':
    print "Hello from __run__.py"
else:
    print "__main__ not defined when __run__.py is executed"

I put this __run__.py file into the root of the stand-alone jython.jar

Command line:

java -jar jython.jar -jar jython.jar

Printed result:

__main__ not defined when __run__.py is executed

This is not what is expected of a main program's startup script, and
has resulted in at least one confused email to the jython mailing
list asking why their startup script wouldn't run.

Well, seems like the __name__ is purposely set after the jar file name
instead of  "__main__" (see org.python.util.jython#runJar). 

So, time to improve docs.

BTW, I'm not implying that the idea of setting __name__ to foo.jar is a
good one, since it's not consistent with the way python modules can be
run from command line (the -m switch).

However, I guess that the backwards compatibility argument wins here.

Docs improved on
<http://wiki.python.org/jython/JythonFaq/DistributingJythonScripts>. 

Unless someone wants to champion a backwards-incompatible modification
here, this is not going to change. Closing.

I doubt that too many applications relied on __name__ being set to the
name of the jar file. Besides, it is redundant.

I changed my __run__.py example program to these 3 lines:
import sys
print "sys.argv:", sys.argv
print "__name__:", __name__

The result:
sys.argv: ['jython.jar']
__name__: jython.jar

So if they need to get the name of the jar file being executed, they can
always get it out of sys.argv[0]

I agree that the current behavior doesn't make much sense. OTOH,
checking for __name__ == '__main__' on __run__.py is also a bit redundant.

The other argument here is that Jython 2.5 implemented the -m option,
which overlaps a bit with -jar. If I had to make a decision, I'd
deprecate -jar in favor or -m, and keep -jar unchanged.

We can't make a change for 2.5.x like this, but we could talk about it
for 2.6 -- maybe you could bring it up on jython-dev to get wider opinions?