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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
