[Python-Dev] methods on the bytes object (was: Crazy idea for str.join)

[Guido van Rossum]

Please take this to the py3k list.

It's still open which methods to add; it'll depend on the needs we
discover while using bytes to write the I/O library.

I don't believe we should add everything we can; rather, I'd like to
keep the API small until we have a clear need for a particular method.
For the record, I'm holding off adding join() for now; I'd rather
speed up the += operation.

--Guido

On 4/30/06, Josiah Carlson <jcarlson at uci.edu> wrote:
>
> "Guido van Rossum" <guido at python.org> wrote:
> > On 4/29/06, Josiah Carlson <jcarlson at uci.edu> wrote:
> > > I understand the underlying implementation of str.join can be a bit
> > > convoluted (with the auto-promotion to unicode and all), but I don't
> > > suppose there is any chance to get str.join to support objects which
> > > implement the buffer interface as one of the items in the sequence?
> >
> > In Py3k, buffers won't be compatible with strings -- buffers will be
> > about bytes, while strings will be about characters. Given that future
> > I don't think we should mess with the semantics in 2.x; one change in
> > the near(ish) future is enough of a transition.
>
> This brings up something I hadn't thought of previously.  While unicode
> will obviously keep its .join() method when it becomes str in 3.x, will
> bytes objects get a .join() method?  Checking the bytes PEP, very little
> is described about the type other than it basically being an array of 8
> bit integers.  That's fine and all, but it kills many of the parsing
> and modification use-cases that are performed on strings via the non
> __xxx__ methods.
>
>
> 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?
>
>
> Anyways, when the bytes type was first being discussed, I had hoped that
> it would basically become array.array("B", ...) + non-unicode str.
> Allowing for bytes to do everything that str was doing before, plus a
> few new tricks (almost like an mmap...), minus those operations which
> require immutability.
>
>
>  - Josiah
>
>


--
--Guido van Rossum (home page: http://www.python.org/~guido/)