Why does b'abc'[0] give 97 while b'abc'[0:1] gives b'a' in Python 3?

## bytes is a sequence of numbers A `bytes` object is defined as an immutable sequence of integers in the range 0 to 255. `bytearray` is the mutable counterpart with the same element type. Python has no "single octet" scalar type, so the natural result of indexing one element is the integer itself: ```python data = b"abc" data[0] # 97 list(data) # [97, 98, 99] sum(data) # 294 ``` The `b'abc'` repr is a display convenience. It prints octets that happen to fall in the printable ASCII range as characters because that is far easier to read than three numbers, and it uses `\xNN` escapes for everything else. Nothing about that repr implies the object holds characters. Slicing behaves differently for a reason that has nothing to do with bytes specifically: in Python, a slice of a sequence is a sequence of the same type. Slicing a list gives a list, slicing a tuple gives a tuple, and slicing a `bytes` gives a `bytes` — even when the slice is one element long. ```python data[0:1] # b'a' data[0] # 97 ``` So the asymmetry is not a special case for `bytes` at all. The special case is `str`. ## str is the odd one out Python has no character type. A `str` is a sequence of code points, but the only object able to hold one code point is a one-character `str`. That makes `str` self-similar: `"abc"[0]` is `"a"`, an object of the same type as its container, and every element of a `str` is itself a `str` containing elements that are `str`. Almost no other sequence in the language works this way. Because developers meet `str` first, its behaviour feels like the rule and `bytes` feels like the anomaly. Reversing that intuition — `bytes` follows the general sequence rule, `str` is the exception — makes the whole family of related surprises predictable. ## The bugs this causes **Iteration yields integers.** The most common form is a scan over a binary buffer comparing against a literal: ```python for octet in data: if octet == b"\n": # never true: int == bytes is False ... if octet == 0x0A: # correct ... ``` The comparison does not raise; it quietly returns `False`, so the loop runs and finds nothing. When you want to compare against a `bytes` literal instead, slice a single element: `data[i:i+1] == b"\n"`. **Containment accepts both.** `b"\n" in data` and `10 in data` are both legal and both do what you would expect — Python 3 allows an integer on the left of `in` for `bytes` as a convenience. That inconsistency with iteration is a fine trap in a code review. **Construction from an int is a count, not a value.** `bytes(3)` is `b'\x00\x00\x00'` — three zero octets — while `bytes([3])` is `b'\x03'` and `b"3"` is the ASCII digit, octet 51. Three superficially similar expressions produce three different objects, and mixing them up in a protocol implementation produces a message the peer rejects for no visible reason. **Construction from text needs a codec.** `bytes("abc")` raises `TypeError: string argument without an encoding`, because turning text into octets always requires a codec choice; `"abc".encode("utf-8")` or `bytes("abc", "utf-8")` are the ways to say it. ## Where it actually bites Protocol and file-format work, where you walk a buffer looking for delimiters, length prefixes and magic numbers. Code written by someone thinking in `str` reads each element and compares it to a one-character literal, and the resulting parser silently accepts everything or finds nothing. Working in integers throughout — comparing to `0x0A`, using integer constants for framing octets — is usually clearer than sprinkling one-element slices, and it makes the intent visible: at that layer you are dealing with numbers, not text. ## What an interviewer is checking This is a curiosity question rather than a gate. Nobody's offer turns on it, but a candidate who can explain it has genuinely internalised that `bytes` is not "a string of ASCII", and that is the model that prevents the harder encoding bugs. Being able to add that `str` is the anomalous self-similar sequence, rather than `bytes` being weird, is the difference between having memorised the behaviour and having understood it.