[Python-Dev] String views

[Michael Chermside]

Tim Delaney writes:
> One of the big disadvantages of string views is that they need to keep
> the original object around, no matter how big it is. But in the case of
> partition, much of the time the original string survives for at least a
> similar period to the partitions.

Why do you say that? Didn't several of Raymond's examples use the idiom:

    part_1, _, s = s.partition(first_sep)
    part_2, _, s = s.partition(second_sep)
    part_3, _, s = s.partition(third_sep)

---

Skip writes:
> I'm skeptical about performance as well, but not for that reason.  A string
> object can have a referent field.  If not NULL, it refers to another string
> object which is INCREFed in the usual way.  At string deallocation, if the
> referent is not NULL, the referent is DECREFed.  If the referent is NULL,
> ob_sval is freed.

Won't work. A string may have multiple referrents, so a single referent
field isn't sufficient.

---

My own contribution:

I know that the Java string class has support for this. The String class
contains a reference to a char array along with start and length indices.
The substring() method constructs what we're calling "string views".

I wonder whether there is a way to instrument a JVM to record how often
the underlying buffers are shared, then run some common Java apps. Since
the feature is exactly analogous to what is being proposed here, I would
find such such analysis very helpful.

-- Michael Chermside