Re: Unix-head needs to Windows-ize his Python script (II)
In message , Dave Angel wrote: > Gee, maybe when "you're trying to track down problems", you might try > starting the application in a console? On a rationally-designed OS, I have a choice. I can do that, but that’s not really my first resort: the first thing I can do is check in ~/.xsession- errors to see if there are already some useful messages that might illuminate the issue. -- http://mail.python.org/mailman/listinfo/python-list
Re: Unix-head needs to Windows-ize his Python script (II)
In message <8ivfa3fif...@mid.individual.net>, Gregory Ewing wrote: > Lawrence D'Oliveiro wrote: > >> You mean “GUI console”. So non-GUI apps get a GUI element whether they >> want it or not, while GUI ones don’t. That’s completely backwards. > > The "G" in GUI stands for "Graphical". I wouldn't call a window that > displays nothing but text "graphical". And yet it takes a GUI to display it. -- http://mail.python.org/mailman/listinfo/python-list
Re: Unix-head needs to Windows-ize his Python script (II)
gb345 wrote: I see how clicking directly on these files would obviate the need to specify the path of the interpreter, but it's still not clear to me how the interpreter would know where to look for the myscript.py module that both the GUI scripts require. If it's in the same directory as the GUI script, or in some known location relative to it, you should be able to locate it based on the fact that sys.path[0] starts off containing the pathname of the directory containing the running script. -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: Unix-head needs to Windows-ize his Python script (II)
Lawrence D'Oliveiro wrote: You mean “GUI console”. So non-GUI apps get a GUI element whether they want it or not, while GUI ones don’t. That’s completely backwards. The "G" in GUI stands for "Graphical". I wouldn't call a window that displays nothing but text "graphical". -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: Unix-head needs to Windows-ize his Python script (II)
On Thu, 28 Oct 2010 12:54:03 +1300, Lawrence D'Oliveiro wrote:
>>> Why would you want both CLI and GUI functions in one program?
>>
>> An obvious example was the one which was being discussed, i.e. the Python
>> interpreter.
>
> But the Python interpreter has no GUI.
It may have one if you use wx, tkInter, etc. So far as the OS is
concerned, it's all python.exe or pythonw.exe.
>> Forcing a program to choose between the two means that we need both
>> python.exe and pythonw.exe.
>
> And yet we get by just fine without this dichotomy on more rationally-
> designed operating systems.
For some definitions of "fine". A GUI-based launcher doesn't know whether
the program it's being asked to run actually needs stdin/stdout/stderr.
Either it spawns an xterm (etc) even if it's not necessary, or it doesn't
and the user can't communicate with the program, or it uses some arbitrary
set of heuristics ("does the program link against Xlib?", which fails if
the GUI portion is loaded dynamically).
>> A less obvious example is a program designed to use whatever interface
>> facilities are available. E.g. XEmacs can use either a terminal or a GUI
>> or both.
>
> And yet it manages this just fine, without Amiga-style invocation hacks, on
> more rationally-designed operating systems. How is that?
Typically by not letting you usefully run terminal-based programs from
the GUI without first having to explicitly configure the invocation
options (e.g. creating a shortcut with "Use terminal" enabled).
--
http://mail.python.org/mailman/listinfo/python-list
Re: Unix-head needs to Windows-ize his Python script (II)
On 2:59 PM, Lawrence D'Oliveiro wrote: In message, Dave Angel wrote: On 2:59 PM, Lawrence D'Oliveiro wrote: In message, Nobody wrote: python.exe is a console executable, pythonw.exe is a GUI executable. Hence python.exe automatically gets a console window, while pythonw.exe doesn't. That's the whole reason why Windows has separate python.exe and pythonw.exe programs, while Unix can use a single /usr/bin/python program for both GUI and console usage. The Windows approach makes it easier to Do The Right Thing automatically ... Except it provides no easy way to capture the contents of that “console”, for when you’re trying to track down problems, because it disappears as soon as the program exits. It would be a stretch indeed to call this “doing the right thing”, automatically or otherwise. Once I realized you had no objective other than Windows bashing, I dropped out of this thread. And yet here you are back again, like a bad smell. If the answer to this present pseudo-complaint isn't obvious to you, you clearly don't know Windows. I was just going by what was said in another thread: As you've noticed, many times a program started from the start menu doesn't leave its command window open long enough to read the messages. Maybe it was the write of this who “clearly doesn’t know Windows”? Gee, maybe when "you're trying to track down problems", you might try starting the application in a console? -- http://mail.python.org/mailman/listinfo/python-list
Re: Unix-head needs to Windows-ize his Python script (II)
In message , Nobody wrote: > On Wed, 27 Oct 2010 13:46:28 +1300, Lawrence D'Oliveiro wrote: > >> Why would you want both CLI and GUI functions in one program? > > An obvious example was the one which was being discussed, i.e. the Python > interpreter. But the Python interpreter has no GUI. > Depending upon the "script", it may need to behave as a command-line > utility (read argv, do stuff, exit), a terminal-based interactive program, > a GUI program, a network server, or whatever. For all the sense your argument makes, you might as well say the same thing about the C run-time library. > Forcing a program to choose between the two means that we need both > python.exe and pythonw.exe. And yet we get by just fine without this dichotomy on more rationally- designed operating systems. > A less obvious example is a program designed to use whatever interface > facilities are available. E.g. XEmacs can use either a terminal or a GUI > or both. And yet it manages this just fine, without Amiga-style invocation hacks, on more rationally-designed operating systems. How is that? -- http://mail.python.org/mailman/listinfo/python-list
Re: Unix-head needs to Windows-ize his Python script (II)
In message , Dave Angel wrote: > On 2:59 PM, Lawrence D'Oliveiro wrote: >> In message, Nobody wrote: >> >>> python.exe is a console executable, pythonw.exe is a GUI executable. >>> Hence python.exe automatically gets a console window, while pythonw.exe >>> doesn't. That's the whole reason why Windows has separate python.exe and >>> pythonw.exe programs, while Unix can use a single /usr/bin/python >>> program for both GUI and console usage. >>> >>> The Windows approach makes it easier to Do The Right Thing automatically >>> ... >> Except it provides no easy way to capture the contents of that “console”, >> for when you’re trying to track down problems, because it disappears as >> soon as the program exits. >> >> It would be a stretch indeed to call this “doing the right thing”, >> automatically or otherwise. >> > Once I realized you had no objective other than Windows bashing, I > dropped out of this thread. And yet here you are back again, like a bad smell. > If the answer to this present pseudo-complaint isn't obvious to you, you > clearly don't know Windows. I was just going by what was said in another thread: As you've noticed, many times a program started from the start menu doesn't leave its command window open long enough to read the messages. Maybe it was the write of this who “clearly doesn’t know Windows”? -- http://mail.python.org/mailman/listinfo/python-list
Re: Unix-head needs to Windows-ize his Python script (II)
On 2:59 PM, Lawrence D'Oliveiro wrote: In message, Nobody wrote: python.exe is a console executable, pythonw.exe is a GUI executable. Hence python.exe automatically gets a console window, while pythonw.exe doesn't. That's the whole reason why Windows has separate python.exe and pythonw.exe programs, while Unix can use a single /usr/bin/python program for both GUI and console usage. The Windows approach makes it easier to Do The Right Thing automatically ... Except it provides no easy way to capture the contents of that “console”, for when you’re trying to track down problems, because it disappears as soon as the program exits. It would be a stretch indeed to call this “doing the right thing”, automatically or otherwise. Once I realized you had no objective other than Windows bashing, I dropped out of this thread. If the answer to this present pseudo-complaint isn't obvious to you, you clearly don't know Windows. DaveA -- http://mail.python.org/mailman/listinfo/python-list
Re: Unix-head needs to Windows-ize his Python script (II)
On Wed, 27 Oct 2010 13:46:28 +1300, Lawrence D'Oliveiro wrote: > Why would you want both CLI and GUI functions in one program? An obvious example was the one which was being discussed, i.e. the Python interpreter. Depending upon the "script", it may need to behave as a command-line utility (read argv, do stuff, exit), a terminal-based interactive program, a GUI program, a network server, or whatever. Forcing a program to choose between the two means that we need both python.exe and pythonw.exe. A less obvious example is a program designed to use whatever interface facilities are available. E.g. XEmacs can use either a terminal or a GUI or both. -- http://mail.python.org/mailman/listinfo/python-list
Re: Unix-head needs to Windows-ize his Python script (II)
In message , Dennis Lee Bieber wrote: > (The Amiga made it simple -- a shell invocation received a non-zero > argc, with command line parameters in argv; a "clicked" invocation > received argc of 0, and argv pointed to a structure containing the > information from the associated .info file [Workbench only displayed > icons from .info files, unlike Windows displaying everything]). Why would you want both CLI and GUI functions in one program? The *nix philosophy is that a program should do one thing, and do it well. That means a command-line tool should concentrate on being a good command- line tool. For users who want to access that functionality through a GUI, you build a GUI front end which makes use of that tool, and possibly others as well, at the back end. That way, you end up with a minimum of complexity and duplication of functionality, and a maximum of flexibility and power. -- http://mail.python.org/mailman/listinfo/python-list
Re: Unix-head needs to Windows-ize his Python script (II)
In message , Nobody wrote: > python.exe is a console executable, pythonw.exe is a GUI executable. Hence > python.exe automatically gets a console window, while pythonw.exe doesn't. > That's the whole reason why Windows has separate python.exe and > pythonw.exe programs, while Unix can use a single /usr/bin/python program > for both GUI and console usage. > > The Windows approach makes it easier to Do The Right Thing automatically > ... Except it provides no easy way to capture the contents of that “console”, for when you’re trying to track down problems, because it disappears as soon as the program exits. It would be a stretch indeed to call this “doing the right thing”, automatically or otherwise. -- http://mail.python.org/mailman/listinfo/python-list
Re: Unix-head needs to Windows-ize his Python script (II)
On Tue, 26 Oct 2010 14:44:11 +, Grant Edwards wrote: >> There is no difference based on the name of your executable, how it >> is built, or what libraries it links to; the only difference is in >> its run-time behaviour, whether it invokes any GUI functions or not. > > No, we're not talking about whether apps invoke GUI functions or not. > That's completely orthogonal to the issue at hand. We're talking > about whether desktop manager should run the program with > stdin/stdout/stderr connected to /dev/null or connected to a terminal > emulator. > > The windows desktop determines that (like it determines other things) > by looking at the filename. Other desktops generally have that > information associated with the icon/button/menu-entry, not with the > executable's filename. Windows executables contain an embedded type field which distinguishes between GUI and console executables (as well as those for the POSIX subsystem, "native" executables, etc). python.exe is a console executable, pythonw.exe is a GUI executable. Hence python.exe automatically gets a console window, while pythonw.exe doesn't. That's the whole reason why Windows has separate python.exe and pythonw.exe programs, while Unix can use a single /usr/bin/python program for both GUI and console usage. The Windows approach makes it easier to Do The Right Thing automatically, but it's a nuisance if you have a program which doesn't really fit into either of the "console" or "GUI" pigeonholes. -- http://mail.python.org/mailman/listinfo/python-list
Re: Unix-head needs to Windows-ize his Python script (II)
On 2010-10-26, Lawrence D'Oliveiro wrote: > In message , Steve > Holden wrote: > >> and, in fact, the console is only a GUI window in a windowed system. It >> might be one of the console emulation windows that init starts under >> linux, or even a terminal connected to a computer by a serila line, for >> heavens sake. > > But now you're no longer talking about Windows. Windows is the only > one that gets it backwards like this, forcing the creation of GUI > elements for non- GUI-based programs, I've been following this entire thread, and I'm afraid I have no clue at all waht you mean by that last phrase "forcing the creation of GUI elements for non-GUI-based programs". > and not for GUI-based ones. In Windows the default for python applications is that they run in a console session with stdin/stdout/stderr attached to a terminal emulator. The application itself may or may not create GUI windows on its own -- that's independent of whether it's attached to a terminal emulator or not. > More reasonably-designed systems, such as you describe above, make no > such distinction between GUI and non-GUI programs. Sure they do. When you create a launcher item or menu item in most desktops, there's a setting that says whether you want the program run in a terminal window or not. That's exactly the same thing you're controlling under Windows when you set the filename to .py or .pyw. > There is no difference based on the name of your executable, how it > is built, or what libraries it links to; the only difference is in > its run-time behaviour, whether it invokes any GUI functions or not. No, we're not talking about whether apps invoke GUI functions or not. That's completely orthogonal to the issue at hand. We're talking about whether desktop manager should run the program with stdin/stdout/stderr connected to /dev/null or connected to a terminal emulator. The windows desktop determines that (like it determines other things) by looking at the filename. Other desktops generally have that information associated with the icon/button/menu-entry, not with the executable's filename. -- Grant Edwards grant.b.edwardsYow! And then we could sit at on the hoods of cars at gmail.comstop lights! -- http://mail.python.org/mailman/listinfo/python-list
Re: Unix-head needs to Windows-ize his Python script (II)
On Tue, 26 Oct 2010 02:38:43 -0400, Steve Holden wrote: > > I really don't understand what you are trying to say here. Could you > please explain? I know you to be a capable and sensible person, but this > sounds like nonsense to me, so I must be misunderstanding. > I think he's saying that on a Linux desktop, if you define a launcher for an application the default assumption is that its a graphical application. If so, all you need to do is to tell the launcher the program name, what icon to use and what text to put under it. If the application isn't graphical, you do the same as above and also tell the launcher that the program must run in a console window. Simple. Logical. Concise. I assume that what I've just described applies to OS X and virtually all other graphical desktops: I wouldn't know from personal experience because I don't use them. -- martin@ | Martin Gregorie gregorie. | Essex, UK org | -- http://mail.python.org/mailman/listinfo/python-list
Re: Unix-head needs to Windows-ize his Python script (II)
On 10/26/2010 2:08 AM, Lawrence D'Oliveiro wrote: > In message , MRAB wrote: > >> On 25/10/2010 02:19, Lawrence D'Oliveiro wrote: >> >>> In message, Dave >>> Angel wrote: >>> No. GUI programs are marked as win-app, so w stands for "Windows". Non GUI programs run in the console. >>> >>> You mean “GUI console”. So non-GUI apps get a GUI element whether they >>> want it or not, while GUI ones don’t. That’s completely backwards. >> >> No, it's not. The fact that the console is also a GUI window is an >> implementation detail ... > > It is not an implementation detail. It is intrinsic to the way Windows > works. No other OS does it backwards like this. I really don't understand what you are trying to say here. Could you please explain? I know you to be a capable and sensible person, but this sounds like nonsense to me, so I must be misunderstanding. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 PyCon 2011 Atlanta March 9-17 http://us.pycon.org/ See Python Video! http://python.mirocommunity.org/ Holden Web LLC http://www.holdenweb.com/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Unix-head needs to Windows-ize his Python script (II)
In message , Steve Holden wrote: > and, in fact, the console is only a GUI window in a windowed system. It > might be one of the console emulation windows that init starts under > linux, or even a terminal connected to a computer by a serila line, for > heavens sake. But now you’re no longer talking about Windows. Windows is the only one that gets it backwards like this, forcing the creation of GUI elements for non- GUI-based programs, and not for GUI-based ones. More reasonably-designed systems, such as you describe above, make no such distinction between “GUI” and “non-GUI” programs. There is no difference based on the name of your executable, how it is built, or what libraries it links to; the only difference is in its run-time behaviour, whether it invokes any GUI functions or not. -- http://mail.python.org/mailman/listinfo/python-list
Re: Unix-head needs to Windows-ize his Python script (II)
In message , MRAB wrote: > On 25/10/2010 02:19, Lawrence D'Oliveiro wrote: > >> In message, Dave >> Angel wrote: >> >>> No. GUI programs are marked as win-app, so w stands for "Windows". Non >>> GUI programs run in the console. >> >> You mean “GUI console”. So non-GUI apps get a GUI element whether they >> want it or not, while GUI ones don’t. That’s completely backwards. > > No, it's not. The fact that the console is also a GUI window is an > implementation detail ... It is not an implementation detail. It is intrinsic to the way Windows works. No other OS does it backwards like this. -- http://mail.python.org/mailman/listinfo/python-list
Re: Unix-head needs to Windows-ize his Python script (II)
On 10/24/2010 9:40 PM, MRAB wrote: > On 25/10/2010 02:19, Lawrence D'Oliveiro wrote: >> In message, Dave >> Angel >> wrote: >> >>> On 2:59 PM, Lawrence D'Oliveiro wrote: In message , Dave Angel wrote: > Presumably the original pythonw.exe was called that because it's > marked > as a windows-app. In win-speak, that means it has a gui. Applications > that are not so-marked are console-apps, and get a console created if > they weren't already started from one. That's where > stdin/stdout/stderr > get pointed. Which is completely backwards, isn’t it? >>> No. GUI programs are marked as win-app, so w stands for "Windows". Non >>> GUI programs run in the console. >> >> You mean “GUI console”. So non-GUI apps get a GUI element whether they >> want >> it or not, while GUI ones don’t. That’s completely backwards. > > No, it's not. The fact that the console is also a GUI window is an > implementation detail: it happens to be displayed within a GUI > environment. and, in fact, the console is only a GUI window in a windowed system. It might be one of the console emulation windows that init starts under linux, or even a terminal connected to a computer by a serila line, for heavens sake. Let's not go overboard looking for things to disagree about ;-) regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 PyCon 2011 Atlanta March 9-17 http://us.pycon.org/ See Python Video! http://python.mirocommunity.org/ Holden Web LLC http://www.holdenweb.com/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Unix-head needs to Windows-ize his Python script (II)
On 25/10/2010 02:19, Lawrence D'Oliveiro wrote: In message, Dave Angel wrote: On 2:59 PM, Lawrence D'Oliveiro wrote: In message , Dave Angel wrote: Presumably the original pythonw.exe was called that because it's marked as a windows-app. In win-speak, that means it has a gui. Applications that are not so-marked are console-apps, and get a console created if they weren't already started from one. That's where stdin/stdout/stderr get pointed. Which is completely backwards, isn’t it? No. GUI programs are marked as win-app, so w stands for "Windows". Non GUI programs run in the console. You mean “GUI console”. So non-GUI apps get a GUI element whether they want it or not, while GUI ones don’t. That’s completely backwards. No, it's not. The fact that the console is also a GUI window is an implementation detail: it happens to be displayed within a GUI environment. -- http://mail.python.org/mailman/listinfo/python-list
Re: Unix-head needs to Windows-ize his Python script (II)
In message , Dave Angel wrote: > On 2:59 PM, Lawrence D'Oliveiro wrote: >> >> In message >> , Dave Angel wrote: >> >>> Presumably the original pythonw.exe was called that because it's marked >>> as a windows-app. In win-speak, that means it has a gui. Applications >>> that are not so-marked are console-apps, and get a console created if >>> they weren't already started from one. That's where stdin/stdout/stderr >>> get pointed. >> >> Which is completely backwards, isn’t it? >> > No. GUI programs are marked as win-app, so w stands for "Windows". Non > GUI programs run in the console. You mean “GUI console”. So non-GUI apps get a GUI element whether they want it or not, while GUI ones don’t. That’s completely backwards. -- http://mail.python.org/mailman/listinfo/python-list
Re: Unix-head needs to Windows-ize his Python script (II)
On 2:59 PM, Lawrence D'Oliveiro wrote: In message , Dave Angel wrote: Presumably the original pythonw.exe was called that because it's marked as a windows-app. In win-speak, that means it has a gui. Applications that are not so-marked are console-apps, and get a console created if they weren't already started from one. That's where stdin/stdout/stderr get pointed. Which is completely backwards, isn’t it? No. GUI programs are marked as win-app, so w stands for "Windows". Non GUI programs run in the console. Non-gui programs came first, so that's the type that doesn't need any tags. No event loop, no window handlers. GUI programs are the exception. DaveA -- http://mail.python.org/mailman/listinfo/python-list
Re: Unix-head needs to Windows-ize his Python script (II)
In message , Dave Angel wrote: > Presumably the original pythonw.exe was called that because it's marked > as a windows-app. In win-speak, that means it has a gui. Applications > that are not so-marked are console-apps, and get a console created if > they weren't already started from one. That's where stdin/stdout/stderr > get pointed. Which is completely backwards, isn’t it? -- http://mail.python.org/mailman/listinfo/python-list
Re: Unix-head needs to Windows-ize his Python script (II)
On 2:59 PM, Lawrence D'Oliveiro wrote: In message, Tim Golden wrote: If you were to rename the .py to a .pyw it would run without a console window showing up. Presumably the “w” stands for “window”. Wouldn’t it be less confusing if it was the other way round? Presumably the original pythonw.exe was called that because it's marked as a windows-app. In win-speak, that means it has a gui. Applications that are not so-marked are console-apps, and get a console created if they weren't already started from one. That's where stdin/stdout/stderr get pointed. DaveA -- http://mail.python.org/mailman/listinfo/python-list
Re: Unix-head needs to Windows-ize his Python script (II)
In message , Chris Rebert wrote: > On Sat, Oct 23, 2010 at 12:32 AM, Lawrence D'Oliveiro > wrote: > >> In message , Tim >> Golden wrote: >> >>> If you were to rename the .py to a .pyw it would run without a console >>> window showing up. >> >> Presumably the “w” stands for “window”. > > Why not "windowless"? Why mention the fact that you don’t have something? “This car is the “D” model, the “D” standing for “Deluxeless”.” -- http://mail.python.org/mailman/listinfo/python-list
Re: Unix-head needs to Windows-ize his Python script (II)
On Sat, Oct 23, 2010 at 12:32 AM, Lawrence D'Oliveiro wrote: > In message , Tim Golden > wrote: > >> If you were to rename the .py to a .pyw it would run without a console >> window showing up. > > Presumably the “w” stands for “window”. Why not "windowless"? - Chris -- http://mail.python.org/mailman/listinfo/python-list
Re: Unix-head needs to Windows-ize his Python script (II)
In message , Tim Golden wrote: > If you were to rename the .py to a .pyw it would run without a console > window showing up. Presumably the “w” stands for “window”. Wouldn’t it be less confusing if it was the other way round? -- http://mail.python.org/mailman/listinfo/python-list
Re: Unix-head needs to Windows-ize his Python script (II)
> I much prefer the wx version of the GUI over the tk version of my app. Check out Python 2.7's Tkinter support for Tile. The enhanced version of Tkinter that ships with 2.7 supports native OS themes across all platforms giving you very professional looking user interfaces. wx has lots more functionality than Tkinter, but if you're just creating simple user interfaces, then the latest version of Tkinter may be just what you're looking for. Malcolm -- http://mail.python.org/mailman/listinfo/python-list
Re: Unix-head needs to Windows-ize his Python script (II)
gb345 wrote: In Tim Golden writes: On 22/10/2010 15:25, gb345 wrote: 3. Both versions of the app work fine on Windows 7, as long as I do the following: a. run CMD b. cd to where the GUI script and my original script live c. execute either C:\Python27\python myapp_tk.py or C:\Python27\python myapp_wx.py The standard python.org associates .py & .pyw files with the installed interpreter. If you double-click on either of those files it should just run. If you were to rename the .py to a .pyw it would run without a console window showing up. Thanks for the tip! That would be great if I could get it to work. When I click on the (renamed) myapp_tk.pyw or myapp_wx.pyw a console appears and immediately disappears (it just flashes, really), too quickly for me to see what it says. (I imagine it's some error message.) The renamed files still work fine if I run them as shown above, though. You need to create a shortcut on the Windows 7 desktop (not sure of the particulars for 7, but it starts with a right-click). Either while creating the shortcut, or afterwards (with another right-click on the shortcut icon, and selecting Properties [hopefully that was not renamed]) have the startup directory be where ever your script lives, and the command line should read C:\Python27\pythonw myapp_tk.py. *disclaimer: I haven't used Windows 7 yet, so some details may vary. ~Ethan~ -- http://mail.python.org/mailman/listinfo/python-list
Re: Unix-head needs to Windows-ize his Python script (II)
In Tim Golden writes: >On 22/10/2010 15:25, gb345 wrote: >> 3. Both versions of the app work fine on Windows 7, as long as >> I do the following: >>a. run CMD >>b. cd to where the GUI script and my original script live >>c. execute either >> >> C:\Python27\python myapp_tk.py >> >> or >> >> C:\Python27\python myapp_wx.py >The standard python.org associates .py & .pyw files with >the installed interpreter. If you double-click on either >of those files it should just run. If you were to rename >the .py to a .pyw it would run without a console window >showing up. Thanks for the tip! That would be great if I could get it to work. When I click on the (renamed) myapp_tk.pyw or myapp_wx.pyw a console appears and immediately disappears (it just flashes, really), too quickly for me to see what it says. (I imagine it's some error message.) The renamed files still work fine if I run them as shown above, though. I see how clicking directly on these files would obviate the need to specify the path of the interpreter, but it's still not clear to me how the interpreter would know where to look for the myscript.py module that both the GUI scripts require. ~G -- http://mail.python.org/mailman/listinfo/python-list
Re: Unix-head needs to Windows-ize his Python script (II)
On 22/10/2010 15:25, gb345 wrote: 3. Both versions of the app work fine on Windows 7, as long as I do the following: a. run CMD b. cd to where the GUI script and my original script live c. execute either C:\Python27\python myapp_tk.py or C:\Python27\python myapp_wx.py The standard python.org associates .py & .pyw files with the installed interpreter. If you double-click on either of those files it should just run. If you were to rename the .py to a .pyw it would run without a console window showing up. TJG -- http://mail.python.org/mailman/listinfo/python-list
