Re: [Python-Dev] String views (was: Re: Proof of the pudding: str.partition())
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. 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. Skip ___ 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
Re: [Python-Dev] String views (was: Re: Proof of the pudding: str.partition())
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 > Tim> survives for at least a similar period to the partitions. > > Not necessarily. Presumably a string view would reference another > string > object's data buffer. A possible optimization would be to convert > from a > view to a normal string once the original strings' refcount dropped > to one, > particularly if the view's size was substantially smaller than that > of the > original string. I suspect this would be a pessimization most of the time, as it would require keeping a list of pointers to all the views referencing the string object. James ___ 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
Re: [Python-Dev] String views (was: Re: Proof of the pudding: str.partition())
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 necessarily. Presumably a string view would reference another string object's data buffer. A possible optimization would be to convert from a view to a normal string once the original strings' refcount dropped to one, particularly if the view's size was substantially smaller than that of the original string. Skip ___ 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
Re: [Python-Dev] String views (was: Re: Proof of the pudding: str.partition())
[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 could be a real advantage to using string views. And I don't even know that. 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. Tim Delaney ___ 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
Re: [Python-Dev] String views (was: Re: Proof of the pudding: str.partition())
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 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
