Some oddities in 2.3b1, esp. with Tkinter

[Russell E. Owen]

In article <m3smrzg3q2.fsf at mira.informatik.hu-berlin.de>,
 martin at v.loewis.de (Martin v. Lowis) wrote:

>"Russell E. Owen" <no at spam.invalid> writes:
>
>> >> 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
>[...]
>> 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.
>
>I see. Please find out what fontName is, and submit a bug report to SF.

I don't think there's a bug. I realized on further investigation that my 
old test caught font names that were ordinary strings but with 
characters with ordinal not in range(128). This worked because in Python 
2.2.2/Tk 8.4.1 the list of font names solely consisted of ordinary 
strings (never unicode), though some names had unprintable characters.

What's new in Python 2.3b1/Tk 8.4.2 is that the list of font names 
returned by tkFont.Font contains some unicode "strings" (what is the 
right term for that?). Those cause the unicode function to raise 
TypeError.

If font names are never supposed to be unicode then I'll report it, but 
it seems like a good idea to me. Some of the asian font names certainly 
look as if they need unicode to be properly expressed.

>Ah, so the Aqua Tcl is multi-threaded. Bad choice. There is not much
>we can do: Tcl threading and Python threading are incompatible. A Tcl
>interpreter can be used only from the thread in which it is created.

I'm very confused about why this will hurt. My Python/Tkinter app will 
not call Tkinter from anything other than the main Python thread. (That 
used to be forbidden and it's a restriction I'm quite comfortable with). 

Also, I don't plan to do low level stuff with tcl from my Python/Tkinter 
app (such as launching additional tcl threads). At least not on purpose 
(perhaps something like createfilehandler violates that rule without my 
knowing).

So I'm hoping that my Python/Tkinter app will be doubly safe -- never 
launch a tcl thread and never call Tkinter from more than one thread -- 
and thus never get me into trouble.

However, a lot of different folks will be using my Python/Tkinter 
application on MacOS X, various flavors of unix and Windows. I'm sure 
some of them will have the threaded version of Tcl/Tk installed. I'm 
sure hoping that'll be OK.

>> >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 recommend to *always* use
>tkapp.createfilehandler. _tkinter.createfilehandler is only supported
>for backwards compatibility, and cannot be supported in threaded Tcl.

That sounds perfect. One call to handle both cases!

Unfortunately, so far I've not been able to find tkapp. It doesn't seem 
to be a module in Tkinter or in Tkinter.Tk nor an attribute of root = 
Tkinter.Tk(). And none of these has a function createfilehandler. (I did 
find a Tkinter file tkappinit.c but reading it was not enlightening).

-- Russell