Message44194
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... |
|
Date |
User |
Action |
Args |
2007-08-23 15:28:08 | admin | link | issue764217 messages |
2007-08-23 15:28:08 | admin | create | |
|