Does PIL work with Tk 8.5?

[Kevin Walzer]

I'm using a build of Python 2.5.1 on OS X 10.5.1 that links to Tk 8.5.
Trying to test PIL with this new build, Python barfs when trying to
display an image in a Tkinter Label. Here is my sample code:

---
from Tkinter import *
import Image, ImageTk

root = Tk()

im = Image.open('/Users/kevin/Desktop/to.jpg')
newim = im.resize((16, 16))

labelimage = ImageTk.PhotoImage(newim)

w = Label(root, text="My Test Icon", image=labelimage, width=100)
w.image=labelimage
w.pack()

mainloop()
--

Here's the error message:

Macintoshesktop kevin$ python iconlabel.py
alloc: invalid block: 0x5c32b4: 5d 0 0

Abort trap
Macintoshesktop kevin$


The build of PIL was made against the pre-compiled binary of Python for
OS X (from python.org) that links to Tk 8.4.

Since Python itself is the same version number (2.5.1), the only thing I
can find to account for the crash is the different version of Tk--could
this be making a difference, or am I doing something wrong?

 

[Martin v. Löwis]

Since Python itself is the same version number (2.5.1), the only thing I

can find to account for the crash is the different version of Tk--could
this be making a difference, or am I doing something wrong?

Yes, Tk 8.5 isn't quite compatible with existing Tkinter code; there
have been a lot of changes which break Tkinter applications (though not
Tkinter itself).

OTOH, it's more likely that the PIL binaries you are using conflict with
your Tk installation - if the binaries were for Tk 8.4 (which isn't
quite clear to me whether that's indeed the case), then they can't work
with Tk 8.5, as Tk doesn't provide that kind of binary compatibility.

Regards,
Martin

 

[Kevin Walzer]

OTOH, it's more likely that the PIL binaries you are using conflict with
your Tk installation - if the binaries were for Tk 8.4 (which isn't
quite clear to me whether that's indeed the case), then they can't work
with Tk 8.5, as Tk doesn't provide that kind of binary compatibility.

Tk itself has a stubs mechanism that allows libraries compiled against
earlier versions to be used with later versions. It's different than
Python in this respect. A pure-Tk library (such as Img or TkPNG) built
against Tk 8.4 would not require re-compilation to be used with 8.5.
Since PIL is a Python library, however, you may be right.

 

[Kevin Walzer]

Tk itself has a stubs mechanism that allows libraries compiled against
earlier versions to be used with later versions. It's different than
Python in this respect. A pure-Tk library (such as Img or TkPNG) built
against Tk 8.4 would not require re-compilation to be used with 8.5.
Since PIL is a Python library, however, you may be right.

Indeed, this appears to be the problem. I tested my script against the
Python bundled with Mac OS X, which links against 8.4, and it worked fine.

 

[Martin v. Löwis]

Tk itself has a stubs mechanism that allows libraries compiled against

earlier versions to be used with later versions. It's different than
Python in this respect. A pure-Tk library (such as Img or TkPNG) built
against Tk 8.4 would not require re-compilation to be used with 8.5.
Since PIL is a Python library, however, you may be right.

But aren't the older binaries linked, in a hard-coded manner, against
libtk8.4.so.0 (or .dylib)? If so, how does it help that the Tcl stub
layer could still provide binary compatibility? Won't the operating
system load and use the older Tk version *anyway*?

Regards,
Martin