Some oddities in 2.3b1, esp. with Tkinter

[Russell E. Owen]

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.
>>             try:
>>                 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 
>tkapp.createfilehandler instead.

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?
>
>> Example:
>> 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:
>> root.getvar(x)
>> 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 
lives?

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