This is an acedmic note. This is not really the place and perhaps better moved to a PEP or a forum. 

In my search to discover more about Python ( and its interactive interpreter and its help() function? statement? on my own) I noticed it was kind of a wart in Python world. It seems like the print statement or the exit() interactive interpreter command in someways.

I was not able to pass in any arguments into "help()" or pipe in "modules" into it from the DOS command line.

For example while you are in the Python interactive command interpreter; you can not call "help()" like a function; such as:
 "help(modules)" 

Nor will this work: ">>>help();modules" in the interactive interpreter  as "modules" is considered a seperate attempted statement (which raises and exception because "modules" is not a valid __builtin__ object.

It seemed like Python's help() command is its own little interactive interpreter. Like it's own seperate subprocess. Is it? I don't know, not likely. But that's how it behaves to me. Which lead me thinking in another direction. 

So I tried these commands knowing they wouldn't work but leads to an idea:

c:\python.exe -c help(modules)   # help() is not a classic function it seems; perhaps it should be
c:\python.exe -c help();modules  # definitly wrong
c:\python.exe -h modules         # looks like a viable idea; perhaps a nice PEP?

Which led me to try to find a way to run the help() command in it's own seperate process or subprocess. So if it failed it wouldn't effect python.exe. Well the help() command appears to be baked right into the python.exe program. So perahps a seperate second python.exe subprocess to test the idea that help() should eventaully be an actual subprocess with the ability to check on failure of "help()"-"modules"; or anything like it; a design change of python.exe

I started with:
c:\python.exe -c "import os; os.system('python.exe -c help()')"

Some problems with this attempt is: 1. os.system() is being obseleted for the subprocess.Popen() module. 2. There are MS-DOS command prompt quotation issues with trying to get "modules" piped into the new process somewhere at the end of that. 3. Lots of other stuff.

Anyway I moved forward with the idea to test this code within the python.exe interactive interpreter to test:

# code
from subprocess import Popen, PIPE
cmds = ['python.exe', '-c', 'help()']
p1 = Popen(cmds, stdout=PIPE, stdin=PIPE)
print p1.communicate("modules")[0]
# end code

On my system the app model popup still pop's up behind the ORIGINAL cmd.exe window. Therefore still the same problem and potential of crashing. 

So digging further I came to 
http://docs.python.org/library/subprocess.html

Quoted from website "The startupinfo and creationflags, if given, will be passed to the underlying CreateProcess() function. They can specify things such as appearance of the main window and priority for the new process. (Windows only)" and then changing the code to:

# code
from subprocess import Popen, PIPE, CREATE_NEW_CONSOLE
cmds = ['python.exe', '-c', 'help()']
p1 = Popen(cmds, stdout=PIPE, stdin=PIPE, creationflags=CREATE_NEW_CONSOLE)
print p1.communicate("modules")[0]
# end code

which does seem to force the modal popup to the top of the DOS command window. See URL: 
http://msdn.microsoft.com/en-us/library/ms684863(v=VS.85).aspx


Why this tangent on a basically esoteric issue? 
One reason is security. I see this as a way a hacker can crash Python apps easily. A horrible thing on a webserver with Python served webpages.