[Pythonmac-SIG] Another tcl/tk problem with python--PIL this time

Russell E. Owen rowen at cesmail.net
Mon Oct 30 23:37:38 CET 2006

You'll recall that I reported crashes with the macpython.org matplotlib 
package. This turned out to be because I was using my own Tcl/Tk (a good 
version instead of the version installed with 10.4).

It turns out PIL has a similar but more subtle problem. It works for me, 
but if I use py2app to bundle an application that uses PIL, it fails one 
some users machines. Building a new PIL locally fixes the problem, of 

This is another plea for the _tkinter.so that comes with the standard 
macpython to be set up to look for a Tcl/Tk first in 
/Library/Frameworks, then in /System/Library/Frameworks. I think the 
packages would have just worked fine with that change (though i've not 
ripped out my Tcl/Tk to prove that).

The current situation is nasty:
- Any serious Tcl/Tk/Tkinter user will install a better version of 
Tcl/Tk on MacOS X.
- MacPython needs a simple modification to support it:
- But this modification breaks matplotlib and PIL, and perhaps any 
python package installed with a binary installer built on an unmodified 

I know there is talk of including a Tcl/Tk with Python like Windows 
does. I hope we don't do that because, based on my experience with 
Tcl/Tk on Mac, unix and Windows, the Windows solution is the worst of 
the lot:
- It makes upgrading tcl/tk harder. Serious users of Tcl/Tk want this to 
get useful bug fixes (no package that large is perfect).
- It makes installing tcl/tk additions harder (for example I use the 
snack sound library). On Windows it's not easy to figure out where to 
put these extensions, nor is it easy to test them!

Modifying _tkinter.so is trivial and it does the job. If it was part of 
the standard MacPython distro then the problem with broken extensions 
would probably be solved. If proof of that assertion would tip the 
balance, I'm willing to do more leg work on it.

-- Russell

More information about the Pythonmac-SIG mailing list