Best GUI for Python

Chris Angelico rosuav at
Tue Apr 28 07:32:35 CEST 2015

On Tue, Apr 28, 2015 at 3:10 PM, Steven D'Aprano
<steve+comp.lang.python at> wrote:
> On Monday 27 April 2015 17:22, Chris Angelico wrote:
>> This is a problem that won't just "go away". As more SMP blocks get
>> assigned, more people will start using them, and get frustrated at
>> your program for not letting them. (And why should an end user need to
>> know the difference between 😃 and ⍥, that the second one works and
>> the first doesn't?) Unless you're willing to wait for a Python that
>> ships Tcl 9, Tkinter is a choice that restricts your end users.
> I'm not really arguing with you, just giving a slightly difference of
> emphasis...
> I don't think that failure to support the SMPs is a deal-breaker. Obviously,
> if you specifically need some subset of Unicode in the SMPs, say Phoenician,
> then it may be, but I'm just talking about general use. Given the generally
> poor support for non-ASCII characters many applications provide, any Unicode
> support is better than none.

I agree that it isn't _in itself_ a deal-breaker; it's a choice, but
most choices restrict you, the programmer. Choosing to use Python
rather than C restricts what you can do easily (but so would the
converse choice); choosing to use SQLite3 restricts your ability to
alter tables; choosing to use PyGTK forces you to include an external
dependency. But choosing to use Tkinter restricts *your users* to
BMP-only. That's a consideration that takes a bit more thought to
evaluate; how bad is it? You can decide on the cost of a UTF-8 string
type by figuring out how often you need to know about character
lengths, but how can you know the cost of a UCS-2 font renderer?

That's why I would be inclined to avoid Tkinter. Not because UCS-2 is
a fundamental deal-breaker, but because it's too hard to truly
evaluate the merits of the decision. Maybe external deps are just too
costly (like for Idle), or maybe you just detest all the other
options, and so maybe you'll end up coming back to Tk; but at the
initial evaluation phase, I would push for something else if at all

There's often some sort of problem with non-ASCII text in a program
that wasn't built for it. A lot of programs I use (including some that
I've written) have issues with RTL text - particularly, issues with
mixed RTL and LTR text on the same lines, which is a pretty hairy
problem. But at least if a program uses Python 3, it has a good chance
of getting most of it right. As you say, that's a huge advantage over
so many applications. :(


More information about the Python-list mailing list