This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author reowen
Recipients
Date 2004-08-23.20:14:02
SpamBayes Score
Marked as misclassified
Message-id
In-reply-to
Content
Logged In: YES 
user_id=431773

Thank you very much for submitting this patch.

At risk of submarining this useful patch, I fear the __del__ 
change may be important.

The main point of the patch is so that Tkinter users can deal with 
a tk named font when all they have is the name. So...what can go 
wrong with deleting the tk named font when a tkFont object goes 
away?

Consider the following sequence:
- subroutine A creates a tkFont, which creates a new tk named 
font
- subroutine B knows the name of the font, but does not have the 
original tkFont object. So it creates a copy using name=...
- subroutine A finishes with the tkFont object and so it is garbage-
collected
- subroutine B's tkFont object mysteriously stops working because 
the underlying tk named font has been destroyed.

I found this sequence occurring in my own test code and it is the 
reason I deleted the __del__ object.

Other arguments for not deleting tk named fonts when tkFont 
objects go away:
- It is important if one has used named fonts to configure widgets 
(and this is the primary reason I know of for creating named 
fonts).
- It matches tk's own behavior.

I don't believe leaving tk fonts around has any significant down 
sides. One can certainly imagine memory use issues, but a user 
would have to create an unreasonable # of fonts to notice 
anything.

An alternative that requires more code is to use a dictionary to 
maintain a reference count by font name. When the count goes 
to zero, delete the tk named font. But yecch...
History
Date User Action Args
2007-08-23 15:28:08adminlinkissue764217 messages
2007-08-23 15:28:08admincreate