[Tkinter-discuss] tkFont issue; what patch will fly?

Russell E. Owen rowen at cesmail.net
Thu Mar 30 00:07:37 CEST 2006

In article <20060329210742.GD13299 at unpythonic.net>,
 Jeff Epler <jepler at unpythonic.net> wrote:

> This sounds similar to the problem with Tk images and Python refcounting.
> If there's a better solution for fonts, maybe it can be applied to
> images too.  If there's not a clearly better solution, fonts should do
> the same thing as images.

I'm not sure this is a useful analogy because images are not like named 

An image is huge, so special memory management makes some sense. tk 
named fonts are tiny.

An application may potentially handle huge #s of images (e.g. an image 
processing app), but there's no obvious reason for an application to 
have many named fonts.

An image is visible; if it goes away you can see that immediately (even 
if it's confusing, at least you can see it when it happens). A tk named 
font is not visible; if it goes away it may be a long time before the 
application notices (e.g. next time one tries to adjust the displayed 
font for a set of widgets), making the issue very hard to track down.

If there really is a valid use case for an application creating hordes 
of named fonts and ditching them later, then perhaps my second 
suggestion is necessary -- delete only when the tkFont.Font object that 
created the tk named font goes away, not if the tkFont.Font object is a 
copy of an existing named font.

Personally I'd rather get rid of the __del__ method entirely and let tk 
named fonts persist. But either solution is clearly preferable to the 
current situation.

-- Russell

P.S. I'm curious...how many of you have used named fonts, and what do 
you use them for? I get the feeling they're not widely used. In my case 
I have a cross-platform app with a few user-settable fonts.

More information about the Tkinter-discuss mailing list