On 12/30/06, Talin <[EMAIL PROTECTED]> wrote: > Maybe this would be a good time to review, or at least restate, the > specific plans for strings in Py3K? I know that there's been a great > deal of discussion on this, but a lot of that discussion took place > *before* Larry's work (specifically, before a number of people in this > group drank the lazy-strings KoolAid.)
The *only* think that I care about is that we end up with a single string type named 'str' that has the same semantics (and some of the same performance) as the current Unicode strings. (I mention performance because s[i] should remain an O(1) operation.) I don't particularly care about preserving the C API except from a practical standpoint -- changing all uses of strings would require modifying nearly every other line of the interpreter code, so a decent amount of backward compatibility will help us meet the deadline (of an alpha release by the end of Q2 '07). > I'm specifically concerned about avoiding confusion over the "lazy" > aspect of strings, because there's two kinds of "laziness" that has been > discussed here: Lazy string manipulation (slice and join), and lazy > format conversion (8-bit, 16-bit, 32-bit.) Both are, I think, desirable. > They are also inter-related, in that the design of one likely affects > the other, so I don't think it makes sense to discuss these issues in > isolation. > > Is there a PEP which defines what is going to happen? I specifically > refer to issues of: > > -- Internal representation of varying-width string encodings > -- On-the-fly encoding changes > -- C API changes > -- String 'views' > -- Lazy slicing and concatenation. > -- Performance expectations for all of the above. I tuned out the endless discussions about this, and I doubt that anyone is really eager to repeat them. At this point I prefer to let code speak. If someone thinks they can do better, let them produce a competing patch, and a benchmark that we can agree on. It seems unlikely that we'll be able to address all the issues you mention without doing a lot of implementation work; while I don't recommend jumping in without doing some serious thinking, I really don't want to get back in the mode of endless discussion without a basis in fact. -- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
