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 loewis
Recipients
Date 2003-07-13.15:57:37
SpamBayes Score
Marked as misclassified
Message-id
In-reply-to
Content
Logged In: YES 
user_id=21627

While the bug might be worth fixing, I think the approach
taken is wrong. With the patch, it will invoke "font names"
for all new tkFont objects, which might be a significant
overhead.

To really preserve current behaviour, it should continue to
'font create', and fall back to 'font configure' in case of
an exception.

Actually, it is not clear what the right behaviour is in the
first place. 'font configure' would change the settings of
the existing font. If the name clash is by coincidence, it
would be better to raise an exception instead of silently
modifying the existing font.

In the face of ambiguity, refuse the temptation to guess.

So to really fix this, tkFont.forName (or tkFont.existing)
should be provided.
History
Date User Action Args
2007-08-23 15:28:08adminlinkissue764217 messages
2007-08-23 15:28:08admincreate