Best GUI for Python

Rustom Mody rustompmody at
Wed Apr 29 06:05:31 CEST 2015

On Monday, April 27, 2015 at 12:52:48 PM UTC+5:30, Chris Angelico wrote:
> On Mon, Apr 27, 2015 at 4:55 PM, Christian Gollwitzer  wrote:
> > Am 27.04.15 um 01:06 schrieb Chris Angelico:
> >>
> >> On Mon, Apr 27, 2015 at 6:26 AM, Ben Finney 
> >> wrote:
> >>>
> >>> It doesn't have to. By using the newer ‘tkinter.ttk’ library
> >>> <URL:>, the GUI will
> >>> use native look-and-feel widgets.
> >>>
> >> Does the new library also deal with the ongoing issues with Unicode
> >> support? AIUI there's some fundamental problem with Tkinter which
> >> means that (possibly only on Windows?) non-BMP characters simply can't
> >> be displayed.
> >
> >
> > No. That is a fundamental limit in Tcl 8 (it uses UCS-2 to store strings),
> > and will probably only addressed in Tcl 9. ttk addresses mostly the theming
> > issue and is now "8 years new" (Tk 8.5a6) with a precursor (Tile) from ten
> > years ago.
> Right, so this is an ongoing issue (at least for now).
> >> To me, that's a pretty bad flaw - we should be aiming
> >> new projects at complete Unicode support, which means Python 3 and a
> >> good GUI toolkit.
> >
> >
> > YMMV. Is non-BMP needed for any living non-esoteric language? I agree that
> > it is a big flaw, but still is useful for very many projects.
> Maybe not for the language itself, but then, you can transliterate
> Chinese using nothing but Roman letters and Arabic numerals (all in
> ASCII), so merely proving that you can represent text doesn't
> necessarily mean everything. Mainly, SMP characters are used for
> things like musical notes, mathematical symbols, emoticons, and so on.
> (Also, I'm not sure of the current state of the art as regards Chinese
> and Japanese characters.) If you support only the BMP, then you're far
> better off than supporting only ASCII or only <some eight-bit code
> page>, to be sure, but it's still cutting out some characters. For a
> program that already exists, already works, and can't handle non-BMP
> characters, it's a small issue, and not one that I'd be recommending a
> complete GUI toolkit replacement for; but for a green-field project, I
> would strongly recommend using Python 3 and some toolkit which
> supports the full Unicode range.

Everything else being equal this is likely fine advice.
However everything is rarely equal; eg the one time I tried to use wxpython
it segfaulted, probably the only time in 15 years of python-use that Ive
got python to segfault.

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

The issue is a bit subtle and nuanced
Python is 2 (at least) things
1. A fine unicode supporting framework
2. A glue for putting together systems composed of various components

Since some of those *other* components may break, it would be good for the
'glueness' of python to break more smoothly than it currently does.
is a very non-exhaustive list – not just Tkinter – of 
- ostensibly unicode-supporting 
- actually SMP-borked

IOW it would be good if bugs (enhancements actually) like these be resolved:

More information about the Python-list mailing list