RE Module Performance
Terry Reedy
tjreedy at udel.edu
Wed Jul 24 13:52:39 EDT 2013
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
More information about the Python-list
mailing list