Some oddities in 2.3b1, esp. with Tkinter

[Martin v. Löwis]

"Russell E. Owen" <no at spam.invalid> writes:

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

I call them either unicode strings, or unicode objects; the "plain"
strings I call byte strings.

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

I see. This is most likely a Tk change: It would have been a bug that
the platform font names where in the platform local encoding in Tk and
not in UTF-8; when Tk fixes this, Python will return the UTF-8 strings
as Unicode objects.

Displaying those in a menu should work out of the box, whereas I can
believe that Tk failed to properly display the strings when they were
still encoded in the platform encoding.

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

Calling Tk from a different thread was not really forbidden in the
past, and still isn't forbidden, and was even supported, and still is.

The problem is that Python cannot tell whether the call comes from
"the main thread" (i.e. the one that is dispatching events), and Tcl
will crash if it is multi-threaded and the call comes from the wrong
thread.

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

That is correct.

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

_tkinter is now "safe" with a threaded Tcl in the sense that it will
reject calls made to a threaded Tcl which can't be
supported. Unfortunately, this includes calls which are supported when
made to a non-threaded Tcl (i.e. essentially all earlier Tcl
installations). In most cases, the rejected calls will be module-level
calls, and changing them to tkapp calls would have _tkinter accept the
call.

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

The ".tk" attribute of any widget will be a tkapp object.

Regards,
Martin