James> I suspect this would be a pessimization most of the time, as it
James> would require keeping a list of pointers to all the views
James> referencing the string object.
I'm skeptical about performance as well, but not for that reason. A string
object can have a referent field.
On Aug 31, 2005, at 10:21 PM, [EMAIL PROTECTED] wrote:
>
> Tim> One of the big disadvantages of string views is that they
> need to
> Tim> keep the original object around, no matter how big it is.
> But in
> Tim> the case of partition, much of the time the original string
> Ti
Tim> One of the big disadvantages of string views is that they need to
Tim> keep the original object around, no matter how big it is. But in
Tim> the case of partition, much of the time the original string
Tim> survives for at least a similar period to the partitions.
Not necessar
[EMAIL PROTECTED] wrote:
> How would this work? One of the advantages of the current string is
> that the underlying data is NUL-terminated, so when passing strings
> to C routines no copying is required.
I didn't say it would be easy. Just that it's about the first cases
where I've seen there c
Skip> OTOH, maybe that would work. Perhaps we should try it.
Ah, I forgot the data is part of the PyString object itself, not stored as a
separate char* array. Without a char* in the object it's kind of hard to do
views.
Skip
___
Python-Dev maili
Tim> I'm actually starting to think that this may be a good use case for
Tim> views of strings i.e. rather than create 3 new strings, each
Tim> "string" is a view onto the string that was partitioned.
How would this work? One of the advantages of the current string is that
the underl
