[Pythonmac-SIG] Difference between pythonw and python?

[Jens Miltner]

Am 01.04.2004 um 22:32 schrieb Jack Jansen:

>
> On 1 Apr 2004, at 17:05, Bob Ippolito wrote:
>
>> On Mar 31, 2004, at 2:46 AM, Jens Miltner wrote:
>>
>>> What exactly (at the code level) is the difference between pythonw  
>>> and python?
>>> The reason I'm asking is that I'm trying to get Tkinter work with an  
>>> application that links against Python.framework and uses python as  
>>> it's scripting language (MacCvsX).
>>> I do have problems with Tk not being recognized as a valid symbol  
>>> name in the python scripts (despite the fact that those scripts do  
>>> have a "from Tkinter import *" statement and they do work when  
>>> executed from a shell), so I thought this might be related to the  
>>> pythonw vs. python problem...
>>>
>>> Anybody knows what the exact difference between the two is?
>>
>> You have multiple versions of Python installed.  It's highly likely  
>> that your application and any extensions you have built are linking  
>> against /Library/Frameworks/Python.framework (or a homedir version)  
>> but you are running a python interpreter linked to  
>> /System/Library/Frameworks/Python.framework (if you are using OS X  
>> 10.3).  If that is not the exact case, then it's something very much  
>> like that case.
>
> Bob is right, probably. You are apparently using Alexandre Parenteau's  
> MacCVS stuff in your application (I might be giving Alexandre too much  
> credits here, I haven't a clue how many people are involved with  
> MacCVS/WinCVS/cvsGUI, but he was always the main contact point back  
> when I used it a lot). My guess is that this is linked against an  
> older Python framework, probably MacPython 2.2. The warning message  
> about _cvsgui is in a funny place, though, but I assume this is  
> because the warning goes to stderr and the other messages to stdout or  
> something.
>
> Then something happens that I don't fully understand, but it is  
> probably caused by the problem above: _tkinter.so fails to load (or  
> cannot be found), this is the last line.
>
> From here on everything is understandable again: if you do another  
> "import Tkinter" you will get the incomplete Tkinter module that  
> failed to import _tkinter, and hence it misses all the interesting  
> bits.
>
> I think you will be able to reproduce this problem with command-line  
> Python by doing "import cvsgui" before you import Tkinter. You may  
> have to add /Developer/Applications/3rd Party/MacCvs/PythonLib to  
> sys.path before importing cvsgui.
>
> If you manage to reproduce the problem with the commandline: try  
> again, but now run with "pythonw -vv". This will make python *very*  
> verbose on imports, also telling you about the failed attempts.  
> Hopefully this will tell you more, or otherwise send the transcript  
> here again and we'll have a look.

O.k., some more info here:

I tried to import cvsgui from the commandline and that worked (I assume  
the pure "import cvsgui" doesn't do a lot as long as I don't attempt to  
use the objects?) and a following

from Tkinter import *
root=Tk()

also worked fine from the commandline.


I then wrote a macro that dumps out sys.path and found the following  
difference:

from the commandline:
 >>> for p in sys.path:
...     print p
...

/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ 
python23.zip
/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3
/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/ 
plat-darwin
/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/ 
plat-mac
/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/ 
plat-mac/lib-scriptpackages
/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/ 
lib-tk
/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/ 
lib-dynload
/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/ 
site-packages


from MacCvsX's macro execution (executing the same statement as above):

/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ 
python23.zip
/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/
/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/ 
plat-darwin
/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/ 
plat-mac
/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/ 
plat-mac/lib-scriptpackages
/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/ 
lib-tk
/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/ 
lib-dynload
/Developer/Applications/3rd Party/MacCvs/PythonLib


So the "site-packages" path is missing when running from within  
MacCvsX. Since I installed _tkinter using the Packagemanager, that _is_  
the problem:
When I added this path hardcoded for test purposes in our python  
initilization, importing Tkinter worked fine.

Now, the remaining question is: who is adding this path?

Unfortunately, now that I had Tkinter imported properly, I also had to  
find that I run into the exact problem you already mentioned, namely  
Tkinter installing it's own event loop.
Is there any Tk package that won't do this (or launch an external app  
to run the UI)?
How is this solved on other platforms?
Do you know of Tk packages that don't set up a complete event loop, but  
use e.g. CarbonEvents to manage their widgets, so that they don't  
interfere with a hosting app's event handling?
Any better place to ask thow Tkinter-related questions?

</jum>