On 29/04/2015 05:05, Rustom Mody wrote:
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
Those who can do, those who can't teach :)
--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.
Mark Lawrence
--
https://mail.python.org/mailman/listinfo/python-list
