[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
- 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.
More information about the Pythonmac-SIG