On 7/24/2013 11:00 AM, Michael Torrie wrote:
On 07/24/2013 08:34 AM, Chris Angelico wrote:
Frankly, Python's strings are a *terrible* internal representation
for an editor widget - not because of PEP 393, but simply because
they are immutable, and every keypress would result in a rebuilding
of the string. On the flip side, I could quite plausibly imagine
using a list of strings;
I used exactly this, a list of strings, for a Python-coded text-only
mock editor to replace the tk Text widget in idle tests. It works fine
for the purpose. For small test texts, the inefficiency of immutable
strings is not relevant.
Tk apparently uses a C-coded btree rather than a Python list. All
details are hidden, unless one finds and reads the source ;-), but but
it uses C arrays rather than Python strings.
In this usage, the FSR is beneficial, as it's possible to have
different strings at different widths.
For my purpose, the mock Text works the same in 2.7 and 3.3+.
Maybe, but simply thinking logically, FSR and UCS-4 are equivalent in
pros and cons,
They both have the pro that indexing is direct *and correct*. The cons
are different.
and the cons of using UCS-2 (the old narrow builds) are
well known. UCS-2 simply cannot represent all of unicode correctly.
Python's narrow builds, at least for several releases, were in between
USC-2 and UTF-16 in that they used surrogates to represent all unicodes
but did not correct indexing for the presence of astral chars. This is a
nuisance for those who do use astral chars, such as emotes and CJK name
chars, on an everyday basis.
--
Terry Jan Reedy
--
http://mail.python.org/mailman/listinfo/python-list
