Hmm, I have not viewed the patch in question, but I'm curious why we wouldn't want to include such a patch if it were transparent to the user (Python based or otherwise). Especially if it increased performance without sacrificing maintainability or elegance. Further considering the common usage of strings in usual programming, I fail to see why an implementation like this would not be desirable?
If there's a widely recognized argument against this, a link will likely sate my curiosity. Thanks, Mark > -------Original Message------- > From: Josiah Carlson <[EMAIL PROTECTED]> > Subject: Re: [Python-Dev] The "lazy strings" patch > Sent: 21 Oct '06 22:02 > > > Larry Hastings <[EMAIL PROTECTED]> wrote: > > > > I've significantly enhanced my string-concatenation patch, to the point > > where that name is no longer accurate. So I've redubbed it the "lazy > > strings" patch. > [snip] > > Honestly, I don't believe that pure strings should be this complicated. > The implementation of the standard string and unicode type should be as > simple as possible. The current string and unicode implementations are, > in my opinion, as simple as possible given Python's needs. > > As such, I don't see a need to go mucking about with the standard string > implementation to make it "lazy" so as to increase performance, reduce > memory consumption, etc.. However, having written a somewhat "lazy" > string slicing/etc operation class I called a "string view", whose > discussion and implementation can be found in the py3k list, I do > believe that having a related type, perhaps with the tree-based > implementation you have written, or a simple pointer + length variant > like I have written, would be useful to have available to Python. > > I also believe that it smells like a Py3k feature, which suggests that > you should toss the whole string reliance and switch to unicode, as str > and unicode become bytes and text in Py3k, with bytes being mutable. > > > - Josiah > > _______________________________________________ > 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/mark%40pandapocket.com > _______________________________________________ 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
