On 4/30/06, "Martin v. Löwis" <martin at v.loewis.de> 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/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4