Tkinter wart: bug or feature?

[Chad Netzer]

On Friday 15 November 2002 13:36, David Eppstein wrote:
>
> So, just so I'm clear about this, the workaround is to add image = None
> to your procedure, before it returns?

That's not how I took it.  Assuming you actually meant "image1 = None", then 
that would explicitly lose the reference to the Tkinter.Image object, which 
happens anyway once the function returns and the 'image1' variable goes out 
of scope.

What Mike was saying is that:

lbl = Tkinter.Label(win.window, image=image1)

Hands off image1 to the Label object, which eventually becomes a Tcl/Tk 
construct.  However, this does NOT increase the reference count for the 
Tkinter.Image object itself, and so when image1 goes out of scope, it gets a 
reference count of zero, and causes the actual image memory to be deleted, 
which causes Tk to not display the image (because the Tcl/Tk delete command 
was called on it)

In a class, you could just keep a reference to the image to keep it alive as 
long as Tkinter.Label is alive.  But in a function, Tkinter.Label as well as 
Tkinter.Image both go away (the difference is that Tkinter.Label being 
garbage collected does NOT cause the forget and/or destroy method to be 
called on the Tcl/Tk widget itself.)

I agree that it is an inconsistency.  I think I agree with Mike that 
collection of Tkinter.Image should NOT call "image delete" at this point; 
however, that causes other problems (when DOES the Image ever get deleted?)  
Since the python object is destroyed, the name is lost (to Python, not to 
Tk), and so the simplest alternative is to leak.  Not really nice, but hey, 
the Tcl/Tk widget is leaked to (leaked meaning Tk knows about it, but to 
Python, it is gone)

-- 
Bay Area Python Interest Group - http://www.baypiggies.net/

Chad Netzer
cnetzer at mail.arc.nasa.gov