Some oddities in 2.3b1, esp. with Tkinter
Russell E. Owen
no at spam.invalid
Wed Apr 30 20:02:12 CEST 2003
In article <3EAEF1D6.30900 at v.loewis.de>,
"Martin v. Lowis" <martin at v.loewis.de> wrote:
>Russell E. Owen wrote:
>> 1) A filter to remove fonts with non-ascii names (used to filter out
>> stuff that I could not display in a pop-up menu) broke.
>> unicode(fontName, 'ascii', 'strict')
>> return True
>> except UnicodeError:
>> return False
>> Python 2.2 throws UnicodeError. Python 2.3b1 throws TypeError. The fix
>> is trivial (e.g. "except (UnicodeError, TypeError)". The filter is
>> probably not needed anymore anyway, since Tk 8.4.2 can apparently
>> display menu items with non-ascii characters.
>I don't understand. Why do you ever need to convert the *font name*
>to a Unicode string, or why would Python ever fail to do so? Font
>names are ASCII only, all the time, so you can't possibly ever get
>an exception here.
This is not true on MacOS X. I found it out the hard way. The font names
with unicode appear to be asian fonts, at least for the most part.
Originally I naively just grabbed all font names (as returned by a
tkFont.Font object) and tried to display them in an OptionMenu. Boy did
I see a lot of error messages (about undisplayable glyphs). As I say, I
think Tk 8.4.2 can actually display unicode in menus now, but even
so...I don't think any of my users will be wanting to use the fonts with
non-ascii names and it keeps the list down to a semi-sane size.
>> 2) Tk file events are no longer supported:
>> RuntimeError: _tkinter.createfilehandler not supported for threaded Tcl
>> This is painful since it's hard to see how to write a proper networking
>> GUI with Tkinter without file events for reading data. Perhaps I can get
>> them back again by disabling the new threaded tcl support.
>Are you using Debian by any chance? Otherwise, you should not see
>a threaded Tcl.
Hmm...I installed Aqua Tcl/Tk 8.4.2 from a MacOS X binary installer I
found on the net. I'm not sure what options it was built with (though
I'd have guessed the default ones). I can certainly install it from
source if that would help.
>If your Tcl installation is threaded, you should use
Hmmm...so I can first try my usual way of creating a file handler, and
if that fails, then try this? I'll do it. It'd be great to not have to
overhaul my networking code.
>> 3) Tk returning things as objects is nice, but I had this break at least
>> one thing of mine and it will break others (see 4 below):
>> I was assuming that the values in the dictionary returned by
>> tkFont.Font.config() were strings. Fortunately this was easy to fix. A
>> bit disconcerting -- I wonder how many any other little pitfalls like
>> this still buried in my code -- but well worth the cost of the change.
>What is the nature of that change?
>> v = StringVar()
>> v is a <Tkinter.StringVar instance at 0x2c98a0>
>> l = Label(textvariable=v)
>> x = l["textvariable"]
>> x is reported as a <namespaceVarName object at 0x0168b048>
>> but is a _tkinter.Tcl_Obj based on the following traceback:
>> TypeError: getvar() argument 1 must be string, not _tkinter.Tcl_Obj
>Please submit a bug report. This is easy to fix (just invoke
>str() of the Tcl_Obj)
I'd be happy to. Could you please tell me where the Tkinter project
>> 5) Note that Tkinter's handling of font objects does not seem to have
>> changed. I was hoping it would start returning font objects instead of
>> strings, or offer some way to convert the string to a font object, but
>> apparently not:
>Does Tk have the notion of "font objects"?
tkFont.Font is the Tkinter version of Tk's named fonts. I have no idea
if Tk's named fonts are objects. In fact I'd never even heard of tcl
objects until reading about the recent Tkinter changes.
More information about the Python-list