On 4/30/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > Josiah Carlson wrote: > > Specifically in the case of bytes.join(), the current common use-case of > > <literal>.join(...) would become something similar to > > bytes(<literal>).join(...), unless bytes objects got a syntax... Or > > maybe I'm missing something? > > I think what you are missing is that algorithms that currently operate > on byte strings should be reformulated to operate on character strings, > not reformulated to operate on bytes objects.
Well, yes, in most cases, but while attempting to write an I/O library I already had the urge to collect "chunks" I've read in a list and join them later, instead of concatenating repeatedly. I guess I should suppress this urge, and plan to optimize extending a bytes arrays instead, along the lines of how we optimize lists. Still, I expect that having a bunch of string-ish methods on bytes arrays would be convenient for certain types of data handling. Of course, only those methods that don't care about character types would be added, but that's a long list: startswith, endswith, index, rindex, find, rfind, split, rsplit, join, count, replace, translate. (I'm skipping center, ljust and rjust since they seem exclusive to text processing. Ditto for strip/lstrip/rstrip although an argument for those could probably be made, with mandatory 2nd arg.) Unhelpfully y'rs, -- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ 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
