Tkinter wart: bug or feature?

[sismex01 at hebmex.com]

> From: support @ internetdiscovery.com [mailto:support @
> internetdiscovery.com]
> 
> On Sat, 16 Nov 2002 14:57:28 GMT, "Fredrik Lundh"
> <fredrik at pythonware.com> wrote:
> 
> >David Eppstein wrote:
> >
> >> ...or do all the ugly bookkeeping necessary to make sure 
> that image1
> >> gets deleted when and only when it is no longer needed
> >
> >where all the "ugly bookkeeping necessary" is one extra line:
> >
> >    lbl = Tkinter.Label(win.window, image=image1)
> >    lbl.photo = image1
> 
> This is still a bug workaround, just like using global. You're still
> expecting the end user to do ugly bookkeeping, but only for images:
> I don't have to hold a reference to text1 global for it to work.   
> No other commonly used entity in the Tkinter API has this
> counter-intuitive behavior.  It's also very counter-intuitive to what
> Tkinter is wrapping, namelyTk itself.

I've been reading this thread, and it doesn't seem to be a bug
really, but a compromise between the two distinct ways that Python
and Tcl manage their objects; in Python, if you lose all references
to an object, it automagically disappears (including images); in
Tcl, if you lose all references to an image, it doesn't disappear,
you can reclaim it vía "calling it by it's name".

So, what would you propose?

If you don't delete the image (in Tk) when the object is reclaimed,
then the image is still lost to Python, because although Tk remembers
it, Python doesn't.

Maybe using a class dictionary in the Image class could help; when
an image is instantiated *with* a name, upon creation, it's name
is added to this dictionary.  Upon destruction of the Python object,
if it doesn't have a name, Tk's image object is also deleted.

> I've seen a number of different bug workarounds for this, but
> my question remains: is this a bug or feature? It has been
> Benevolently declared to be Not a Bug, but clearly others have had
> trouble with this too. If it's reopened as a bug we can do something 
> about it as there are obvious fixes as I pointed out, but if it's a
> feature there's nothing we can do.

Nothing to *cancel* the current behaviour, but that doesn't
mean you can't make it better.

-gustavo