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:https://docs.python.org/3/library/tkinter.ttk.html>, 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. http://blog.languager.org/2015/03/whimsical-unicode.html#half-assed is a very non-exhaustive list – not just Tkinter – of - ostensibly unicode-supporting - actually SMP-borked software IOW it would be good if bugs (enhancements actually) like these be resolved: http://bugs.python.org/issue23672 http://bugs.python.org/issue18814 http://bugs.python.org/issue22264 -- https://mail.python.org/mailman/listinfo/python-list
