Dev Player <[email protected]> added the comment:
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.
----------
_______________________________________
Python tracker <[email protected]>
<http://bugs.python.org/issue10060>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
