[Python-Dev] String views (original) (raw)
Michael Chermside mcherm at mcherm.com
Thu Sep 1 16:20:58 CEST 2005
- Previous message: [Python-Dev] C coding experiment
- Next message: [Python-Dev] String views
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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, obsval 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
- Previous message: [Python-Dev] C coding experiment
- Next message: [Python-Dev] String views
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]