How to run Python in Windows w/o popping a DOS box?

[Paul Rubin]

Dumb question from a Windows ignoramus:

I find myself needing to write a Python app (call it myapp.py) that
uses tkinter, which as it happens has to be used under (ugh) Windows.
That's Windows XP if it makes any difference.

I put a shortcut to myapp.py on the desktop and it shows up as a
little green snake icon, which is really cool and Pythonic. When I
double click the icon, the app launches just fine and the tkinter
interface does its thing. But Windows also launches a DOS box that
just sits on the screen uselessly. It's potentially useful in that
"print" statements in the Python app can show messages on the DOS box,
but I figure this is a graphical app so I don't plan to show messages
that way. Also, it happens I often want to run lots of instances of
the app simultaneously, and I want to launch them all by double
clicking the icon. That means the whole screen is cluttered with DOS
boxes all over the place. Of course I can minimize them by clicking
the little underscore in the corner of each one, but that really takes
away from the coolness of it all.

Question: is there any simple way to arrange to launch the app from
the desktop, without also launching a DOS box? By simple I mean
without having to mess with some complex packaging/installation system
(McMillan installer?) every time I want to modify the app, which
during development means a few hundred times a day. I have no desire
at all to conceal the source code from the user or anything like that
either.

Thanks.

 

[Leif B. Kristensen]

Paul Rubin skrev:

Question: is there any simple way to arrange to launch the app from
the desktop, without also launching a DOS box?

Just use the .pyw extension instead of .py, and the DOS box
automagically disappears -- or so I have been told ...

 

[Tim Peters]

[Paul Rubin]

Dumb question from a Windows ignoramus:

I find myself needing to write a Python app (call it myapp.py) that
uses tkinter, which as it happens has to be used under (ugh) Windows.
That's Windows XP if it makes any difference.

Nope, the Windows flavor doesn't matter.

I put a shortcut to myapp.py on the desktop and it shows up as a
little green snake icon, which is really cool and Pythonic. When I
double click the icon, the app launches just fine and the tkinter
interface does its thing. But Windows also launches a DOS box that
just sits on the screen uselessly.
....


Question: is there any simple way to arrange to launch the app from
the desktop, without also launching a DOS box? ...

From a DOS box,

ren myapp.py *.pyw

and click on a link to the resulting myapp.pyw instead. It's the
purpose of the .pyw extension on Windows not to "bring up a DOS box".
..pyw is associated with the Windows-specific pythonw.exe.

 

[Bengt Richter]

Dumb question from a Windows ignoramus:

I find myself needing to write a Python app (call it myapp.py) that
uses tkinter, which as it happens has to be used under (ugh) Windows.
That's Windows XP if it makes any difference.

I put a shortcut to myapp.py on the desktop and it shows up as a
little green snake icon, which is really cool and Pythonic. When I
double click the icon, the app launches just fine and the tkinter
interface does its thing. But Windows also launches a DOS box that
just sits on the screen uselessly. It's potentially useful in that
"print" statements in the Python app can show messages on the DOS box,
but I figure this is a graphical app so I don't plan to show messages
that way. Also, it happens I often want to run lots of instances of
the app simultaneously, and I want to launch them all by double
clicking the icon. That means the whole screen is cluttered with DOS
boxes all over the place. Of course I can minimize them by clicking
the little underscore in the corner of each one, but that really takes
away from the coolness of it all.

Question: is there any simple way to arrange to launch the app from
the desktop, without also launching a DOS box? By simple I mean
without having to mess with some complex packaging/installation system
(McMillan installer?) every time I want to modify the app, which
during development means a few hundred times a day. I have no desire
at all to conceal the source code from the user or anything like that
either.

Thanks.

I would try right-clicking the shortcut icon and selecting properties,
then select the shortcut tab and edit the target string with s/python/pythonw/
and then click ok.

Then try double clicking the shortcut icon again.
If that does it, you're home ;-)
If not, post more symptoms.
HTH

Regards,
Bengt Richter

 

[Paul Rubin]

I would try right-clicking the shortcut icon and selecting
properties, then select the shortcut tab and edit the target string
with s/python/pythonw/ and then click ok.

Thanks! I'll try that tomorrow. I never would have figured that out.

 

[pyguy2]

Python.exe starts up a windows console which gives you things stdin,
stderr, and stdout from the C runtime.

Be warned that you do not have those things with the consoleless(?)
pythonw.exe, stuff which MS intends for gui applications.

It reminds me of select() on windows only working halfway (just
w/sockets) because of the history of how all this got added to windows.
A lot of half-way stuff.

john

 

[Paul Rubin]

I would try right-clicking the shortcut icon and selecting
properties, then select the shortcut tab and edit the target string
with s/python/pythonw/ and then click ok.

Then try double clicking the shortcut icon again. If that does it,
you're home ;-) If not, post more symptoms.

Hmm, I clicked properties and the word python doesn't appear in the
shortcut string. The shortcut string simply points to the .py file.
I think Windows knows to run Python because of some registry entry
that maps the .py extension to python.exe. I don't know which entry
and changing it sounds a little bit dangerous.

I did see that I could select a button launch the dos box minimized,
so it doesn't clutter up the screen. That mostly solves the immediate
problem. A more complete solution (eliminate dos box altogether)
would be nice, but I can live with an auto-minimized box.

Thanks.

 

[pyguy2]

click on my computer
Then select tools->folder options->File Types

scroll down the where the py extension is defined, highlight it, click
on advanced
then highlight open and hit the edit button.

There you should see python.exe with some other stuff, change it to
pythonw.exe

Then, in the future, if you click on a python program, it should use
pythonw.exe
The steps should be roughly similar on different versions of windows.

I always liked the #! syntax of unix, too bad MS doesn't have it. And,
too bad their command prompt sucks, too bad process creation is heavy,
too bad . . .

 

[Bengt Richter]

Hmm, I clicked properties and the word python doesn't appear in the
shortcut string. The shortcut string simply points to the .py file.

Ok, in that caseput <proper path>\pythonw.exe in front of that.
If you need to have current working directory some place particular,
there is a "Start in" slot for that on the same property tab.

I think Windows knows to run Python because of some registry entry
that maps the .py extension to python.exe. I don't know which entry
and changing it sounds a little bit dangerous. Right, but you don't have to.

I did see that I could select a button launch the dos box minimized,
so it doesn't clutter up the screen. That mostly solves the immediate
problem. A more complete solution (eliminate dos box altogether)
would be nice, but I can live with an auto-minimized box.

As someone else suggested, you could also change the extension on your script
from .py to .pyw (and make that change in your shortcut too (or delete it
and make a new shortcut to the renamed script), or it won't find the renamed script ;-).

If you type

assoc .py

in a cmd console window, you should get what category of file the windows
registry thinks .py files are. (it uses an intermediate category classification
so that the category can be associated with a program -- e.g., many extensions
might be categorized as text files beside .txt and wind up starting notepad).
To find what's associated with the file category (sorry, type), type

ftype categoryname

For .py and .pyw on my system, you get this:

[ 8:30] C:\pywk\clp>assoc .py
..py=Python.File

[ 8:30] C:\pywk\clp>assoc .pyw
..pyw=Python.NoConFile

[ 8:30] C:\pywk\clp>ftype python.File
python.File=d:\python23\python.exe "%1" %*

[ 8:30] C:\pywk\clp>ftype python.NoConFile
python.NoConFile=D:\Python23\pythonw.exe "%1" %*

To get the whole list of assocs, type it without arg
then pipe to more or window's grep aka findstr (qgrep might be avail too)

[ 8:30] C:\pywk\clp>assoc | findstr py
..py=Python.File
..pyc=Python.CompiledFile
..pyo=Python.CompiledFile

[ 8:30] C:\pywk\clp>ftype | findstr py
Python.CompiledFile=D:\Python23\python.exe "%1" %*
Python.File=d:\python23\python.exe "%1" %*
Python.NoConFile=D:\Python23\pythonw.exe "%1" %*

(I'm not running py24 via association, and in fact rarely let the system do it,
since I need to run python explictly to pipe script input or output due to broken
windows piping in file-associated script execution on my system).

NB: If you type assoc or ftype with the "=" assignment string in format that it shows you,
(e.g. assoc .py=Python.File ) you will non-gui-wise be setting the association in the registry,
assuming you have privilege, so BE CAREFUL with that ;-)

-->> Especially don't mess with .exe association! That was tricky to recover from. (I actually
did that accidentally via Netscape's gui file association thing long ago, not from the command window ;-)

(Start>run>browse can find you regedt32.exe and you can do anything you want
to the registry from there, if you have the information and privilege. The information
part is harder to get that privilege in most cases ;-)

BTW you can do a whole bunch of stuff in the target slot of a shortcut.
E.g., my main one to start a "DOS box" from the start menu[1] has

%SystemRoot%\system32\cmd.exe /x /k prompt [$T$H$H$H$H$H$H] $P$G& d:\vc98\bin\vcvars32.bat & home.cmd & title C++

Which starts cmd.exe with /x options and /k to keep it displayed, changes the prompt, runs the .bat script to
set environment for MSVC++, runs a little command script I made called home.cmd, which enables me easily to
come back to various project "home" directories, and sets a title in the title bar, so my window is ready to go.

A different one can set me up to use Borland's Delphi command line object pascal compiler, etc., settting
appropriate path and other environment variables, so the right set of command utilities are accessible,
and others that might have the same name are not.

[1](which uses shortcuts you can get at via start>settings>taskbar>start-menu-programs> etc)

Hm, I need to set my computer clock ...

Regards,
Bengt Richter

 

[Paul Rubin]

Wow, thanks for that very complete answer. I'll try some of those things.

 

[Bengt Richter]

click on my computer
Then select tools->folder options->File Types

scroll down the where the py extension is defined, highlight it, click
on advanced
then highlight open and hit the edit button.

There you should see python.exe with some other stuff, change it to
pythonw.exe

Then, in the future, if you click on a python program, it should use
pythonw.exe

This change is NOT a good idea!!

Files with .py should almost always run with a console window.
For an execption to that, you can always change a particular shortcut to
do what you like, including bringing it up in gvim instead of running it.
Or you can change the extension to .pyw to get pythonw.exe association.
Or you can run it manually either way.

The steps should be roughly similar on different versions of windows.

I always liked the #! syntax of unix, too bad MS doesn't have it. And,
too bad their command prompt sucks, too bad process creation is heavy,
too bad . . .

What do you mean by "their command prompt"? The actual prompt of cmd.exe
or the command line interpretation? I agree the latter sucks, but I could
change the shell if I wanted to go to the trouble. Sometimes I run msys.
But the actual shell that starts when I log in could be changed too.

Actually, I don't really like os system info mixed in with application
info, which is what #! lines and other file-tagging magic is. I think
it belongs closely associated with the file, but not in it. Likewise
I don't like the use of current-container-name (file name) as content-name
(which should be a persistent name associated with the content, not with
the latest container that happens to contain a copy). But that's another rant ;-)

Regards,
Bengt Richter

 

[pyguy2]

This change is NOT a good idea!!
I agree the .pyw shortcut method is better. However, if you are willing
to lose
stdin,stdout,stderr and really never want a console window to pop up, I
do not see how it is a disasterous change. You can still run python.exe
on your py files when you want to test your code.

What do you mean by "their command prompt"? The actual prompt of cmd.exe
or the command line interpretation? I agree the latter sucks, but I could
change the shell if I wanted to go to the trouble.

Of course, but one cannot always change it on boxes you have to deal
with. Probably in an effort to not compete with themselves, there are
some basic things a multi-hundred dollar operating system doesn't give
you. Like, oh, a simple editor that has multiple levels of undue and
redo.

Actually, I don't really like os system info mixed in with application
info, which is what #!

I think of it like the ''.join semantics. The object knows best how to
handle join (even if it looks wierd to some people). In the #! case,
the program knows best how to start itself.

 

[Bengt Richter]

I agree the .pyw shortcut method is better. However, if you are willing
to lose
stdin,stdout,stderr and really never want a console window to pop up, I
do not see how it is a disasterous change. You can still run python.exe
on your py files when you want to test your code.

Sure, but those are some if conditions ;-) And if it is a shared workstation
and you change it for the all-users profile, people are likely to be upset.

BTW, it is very easy from a C windows program to make a console window
pop up with stdin,stdout,stderr ready to go at the next code line.
It's a win32 C API called AllocConsole and it does nothing if a console window already exists.

I don't know what pythonw.exe does with std i/o that hasn't been intercepted,
but I would think it could be handy to have it force a console window, and maybe
have a pythonw.exe command line option to dump either or both stdout and stderr
silently. That way by default you'd see errors etc. unless you opt now to.
(I should check, maybe they've thought of this already. It's really easy to do)
.... Nope, I don't see it in python -h (and pythonw -h doesn't show anything ;-)

Of course, but one cannot always change it on boxes you have to deal
with. Probably in an effort to not compete with themselves, there are
some basic things a multi-hundred dollar operating system doesn't give
you. Like, oh, a simple editor that has multiple levels of undue and
redo.

Sigh ;-)

I think of it like the ''.join semantics. The object knows best how to
handle join (even if it looks wierd to some people). In the #! case,
the program knows best how to start itself.

This I don't understand ;-)

Regards,
Bengt Richter

 

[John J. Lee]

I agree the .pyw shortcut method is better. However, if you are willing
to lose
stdin,stdout,stderr and really never want a console window to pop up, I
do not see how it is a disasterous change. You can still run python.exe
on your py files when you want to test your code.

[...]

Under some Windows OSes (95/98/ME?) writing to stdout in a Windows app
(.pyw) can crash the Python interpreter.


John

 

[pyguy2]

I think of it like the ''.join semantics. The object knows best how
to

This I don't understand ;-)

With ','.join(['a','b','c']) You rely on what wants to join the
sequence to handle the issue of joining rather than have the sequence
understand joining. I think of it as the object knows best.

I think of #! as "the program knowing best" how to startup, rather
than having to rely on something else to deal with it. I also like the
text based simplicity and explictness. Just like text based "etc" files
on unix versus the registry in windows. And, if you want you can add
more power like use env variables in #!.
It can be as simple or as powerful as you need, you can use whatever
means you want to manage the #! line: text editors, other programs,
etc. It is data-centric, just like http, sql, file I/O rather than
verb-centric (learn another whole set of methods to figure out how to
change startup).

hopefully I am making sense,

john

 

[Bengt Richter]

This I don't understand ;-)

With ','.join(['a','b','c']) You rely on what wants to join the
sequence to handle the issue of joining rather than have the sequence
understand joining. I think of it as the object knows best.

I think of #! as "the program knowing best" how to startup, rather
than having to rely on something else to deal with it. I also like the

My point was that the "program" -- whether script or executable --
_is_ depending on something else, i.e., whatever is launching it
in an appropriate environment, and my real point was that the launcher
looks at the beginning of the file contents to check what to do, rather
than looking at separate file metadata. I am objecting to embeddeding
metadata in data. The convention of using a first #! line in scripts
as metadata and passing the whole script to whatever interpreter
means that the interpreters have to know to ignore the first line
--usually meaning the '#' is a comment line start. Or else it has
to be told with a command line option like python's -x to ignore
extraneous metadata. Carrying metadata in file names and extensions
is not better, just different, and brings a bag of problems, like
having no identifier for the data per se, just its various containers.

text based simplicity and explictness. Just like text based "etc" files
on unix versus the registry in windows. And, if you want you can add
more power like use env variables in #!.
It can be as simple or as powerful as you need, you can use whatever
means you want to manage the #! line: text editors, other programs,
etc. It is data-centric, just like http, sql, file I/O rather than
verb-centric (learn another whole set of methods to figure out how to
change startup).

I don't disagree about the usefulness of various text data, I just
want to distinguish data from metadata and container identifiers
from data identifiers.

hopefully I am making sense,

I think we were just looking a different aspects of the elephant ;-)

Regards,
Bengt Richter

 

[pyguy2]

I am objecting to embeddeding metadata in data.
.....

I think we were just looking a different aspects of the elephant ;-)

I think you are right on both counts.

Given current filesystems, I like the #! method. I tend to like
approaches that have very low entrance access fees and can scale up.
Kinda like python's "hello world" versus Java's. It seems as though
our managing of complexity fails exponentially the more cruft you add
to things. The more you can keep things simple, the further you can
avoid the inflection point.

john

 

[Ron]

I don't know what pythonw.exe does with std i/o that hasn't been intercepted,
but I would think it could be handy to have it force a console window, and maybe
have a pythonw.exe command line option to dump either or both stdout and stderr
silently. That way by default you'd see errors etc. unless you opt now to.
(I should check, maybe they've thought of this already. It's really easy to do)
... Nope, I don't see it in python -h (and pythonw -h doesn't show anything ;-)

Using Editpad Pro to capture std out to an edit panel, I get....

usage: Pythonw [option] ... [-c cmd | file | -] [arg] ...
Options and arguments (and corresponding environment variables):
-c cmd : program passed in as string (terminates option list)
-d : debug output from parser (also PYTHONDEBUG=x)
-E : ignore environment variables (such as PYTHONPATH)
-h : print this help message and exit
-i : inspect interactively after running script, (also PYTHONINSPECT=x)
and force prompts, even if stdin does not appear to be a terminal
-O : optimize generated bytecode (a tad; also PYTHONOPTIMIZE=x)
-OO : remove doc-strings in addition to the -O optimizations
-Q arg : division options: -Qold (default), -Qwarn, -Qwarnall, -Qnew
-S : don't imply 'import site' on initialization
-t : issue warnings about inconsistent tab usage (-tt: issue errors)
-u : unbuffered binary stdout and stderr (also PYTHONUNBUFFERED=x)
see man page for details on internal buffering relating to '-u'
-v : verbose (trace import statements) (also PYTHONVERBOSE=x)
-V : print the Python version number and exit
-W arg : warning control (arg is action:message:category:module:lineno)
-x : skip first line of source, allowing use of non-Unix forms of #!cmd
file : program read from script file
- : program read from stdin (default; interactive mode if a tty)
arg ...: arguments passed to program in sys.argv[1:]
Other environment variables:
PYTHONSTARTUP: file executed on interactive startup (no default)
PYTHONPATH : ';'-separated list of directories prefixed to the
default module search path. The result is sys.path.
PYTHONHOME : alternate <prefix> directory (or <prefix>;<exec_prefix>).
The default module search path uses <prefix>\lib.
PYTHONCASEOK : ignore case in 'import' statements (Windows).

 

[bodoora]

learn python

Hi...
i'm new in python...
if any body have any link (or links) for help me to learn python?
and i want to Know how we can use command of python in command prompt (DOS)?

thanks a lot for help :wavey: