[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 
fonts.

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