RE Module Performance

[Chris Angelico]

On Thu, Jul 25, 2013 at 5:02 PM, Steven D'Aprano
<steve+comp.lang.python at pearwood.info> wrote:
> On Thu, 25 Jul 2013 00:34:24 +1000, Chris Angelico wrote:
>
>> 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.
>
> That's a misleading way to put it. Using immutable strings as editor
> buffers might be a bad way to implement all but the most trivial, low-
> performance (i.e. slow) editor, but the basic concept of PEP 393, picking
> an internal representation of the text based on its contents, is not.
> That's just normal. The only difference with PEP 393 is that the choice
> is made on the fly, at runtime, instead of decided in advance by the
> programmer.

Maybe I worded it poorly, but my point was the same as you're saying
here: that a Python string is a poor buffer for editing, regardless of
PEP 393. It's not that PEP 393 makes Python strings worse for writing
a text editor, it's that immutability does that.

ChrisA