[Python-3000] PEP 3137: Immutable Bytes and Mutable Buffer (original) (raw)

Guido van Rossum guido at python.org
Fri Sep 28 01:03:03 CEST 2007


On 9/27/07, Jim Jewett <jimjjewett at gmail.com> wrote:

On 9/26/07, Guido van Rossum <guido at python.org> wrote:

> Comparisons > ----------- > The bytes and buffer types are comparable with each other and > orderable, so that e.g. b'abc' == buffer(b'abc') < b'abd'. I think bytes (regardless of length) should compare to integers, so that: b"" < -sys.maxint < 97 == b'a' < b'aa' < 98

Argh. Yuck. I'm not even asking for a use case. No.

(Note, I've already decided that b[0] should produce an int, not a 1-size bytes object.)

(zero-length buffer < any integer; otherwise compare the number to the first byte, and in case of ties, a BytesSequence of length 2 or more is greater)

I'm not as sure about comparing to floats. Should they be incomparable to integer sequences? (97, 98) != b'ab' not (97, 98) < b'ab'_ _not (97, 98) > b'ab'

No. There are no precedents for supporting sequence comparisons across type boundaries.

> Bytes and the Str Type > ----------------------

> ... any attempt to mix bytes (or > buffer) objects and str objects without specifying an encoding will > raise a TypeError exception. This is the case even for simply > comparing a bytes or buffer object to a str object ... Should a TypeError be raised as soon as you try to put a bytes and a string in the same dict, even if they don't happen to hash equal?

Good idea, if you can figure out a way to implement this efficiently.

(I assume that buffer(b'abc') in {} will raise a TypeError, just as list("abc") in {} would.)

Indeed. It will fail to hash.

> Therefore, support for the PEP 3118 > buffer API will be removed from the str type.

Good; this may be the single biggest aid for separting characters from a particular (bytes) representation.

Right. Much better than the 3.0a1 approach of explicitly excluding PyUnicode/str where a sequence of bytes is accepted.

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



More information about the Python-3000 mailing list