[Python-Dev] RFC: PEP 460: Add bytes % args and bytes.format(args) to Python 3.5
Stephen J. Turnbull
stephen at xemacs.org
Sat Jan 11 19:44:39 CET 2014
M.-A. Lemburg writes:
> I complete agree with Stephen, that bytes are in fact often
> an encoding of text. If that text is ASCII compatible, I don't
> see any reason why we should not continue to expose the C lib
> standard string APIs available for text manipulations on bytes.
We already *have* a type in Python 3.3 that provides text
manipulations on arrays of 8-bit objects: str (per PEP 393).
> BTW: I don't know why so many people keep asking for use cases.
> Isn't it obvious that text data without known (but ASCII compatible)
> encoding or multiple different encodings in a single data chunk
> is part of life ?
Isn't it equally obvious that if you create or read all such ASCII-
compatible chunks as (encoding='ascii', errors='surrogateescape') that
you *don't need* string APIs for bytes?
Why do these "text chunks" need to be bytes in the first place?
That's why we ask for use cases. AFAICS, reading and writing ASCII-
compatible text data as 'latin1' is just as fast as bytes I/O. So
it's not I/O efficiency, and (since in this model we don't do any
en/decoding on bytes/str), it's not redundant en/decoding of bytes to
str and back.
More information about the Python-Dev
mailing list