RE Module Performance

Chris Angelico rosuav at
Wed Jul 24 16:34:24 CEST 2013

On Thu, Jul 25, 2013 at 12:17 AM, David Hutto <dwightdhutto at> wrote:
> I've screwed up plenty of times in python, but can write code like a pro
> when I'm feeling better(on SSI and medicaid). An editor can be built simply,
> but it's preference that makes the difference. Some might have used tkinter,
> gtk. wxpython or other methods for the task.
> I think the main issue in responding is your library preference, or widget
> set preference. These can make you right with some in your response, or
> wrong with others that have a preferable gui library that coincides with
> one's personal cognitive structure that makes t

jmf's point is more about writing the editor widget (Scintilla, as
opposed to SciTE), which most people will never bother to do. I've
written several text editors, always by embedding someone else's
widget, and therefore not concerning myself with its internal string
representation. 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; whenever text gets inserted, the
string gets split at that point, and a new string created for the
insert (which also means that an Undo operation simply removes one
entire string). In this usage, the FSR is beneficial, as it's possible
to have different strings at different widths.

But mainly, I'm just wondering how many people here have any basis
from which to argue the point he's trying to make. I doubt most of us
have (a) implemented an editor widget, or (b) tested multiple
different internal representations to learn the true pros and cons of
each. And even if any of us had, that still wouldn't have any bearing
on PEP 393, which is about applications, not editor widgets. As stated
above, Python strings before AND after PEP 393 are poor choices for an
editor, ergo arguing from that standpoint is pretty useless. Not that
that bothers jmf...


More information about the Python-list mailing list