What is the difference between Python's str and bytes types?

## Two different sequences A `str` in Python 3 is an immutable sequence of **Unicode code points**. A code point is a number assigned by the Unicode standard to an abstract character — `ord("A")` is 65, `ord("€")` is 8364. A `str` says nothing about how those numbers are stored; CPython picks a compact internal representation for you and you never see it. Indexing a `str` gives you another one-character `str`, and `len()` counts code points. A `bytes` object is an immutable sequence of **octets** — integers in the range 0-255. It carries no notion of characters at all. `len()` counts octets, and the repr is only *displayed* with ASCII-looking escapes for readability; `b"A"` is the single number 65, not a letter. `bytearray` is the same sequence type with mutation allowed. The crucial design decision of Python 3 is that these two types never mix implicitly. There is no automatic promotion, no shared comparison, no concatenation: ```python "a" == b"a" # False "a" + b"a" # TypeError "a".decode() # AttributeError: str has no decode b"a".encode() # AttributeError: bytes has no encode ``` The last two are worth memorising as a shape: `encode` only exists on text (it produces data), `decode` only exists on data (it produces text). If you reach for the wrong one, the exception is telling you that you were confused about which side of the boundary you were standing on. ## The codec is the bridge An **encoding** (a codec) is a rule mapping code points to octet sequences and back. UTF-8 is the one to choose unless something external forces another: it is variable-width, ASCII-compatible for the first 128 code points, and covers the whole Unicode range. ```python s = "café" len(s) # 4 code points b = s.encode("utf-8") # b'caf\xc3\xa9' len(b) # 5 octets b.decode("utf-8") == s # True ``` That length difference is the single most useful thing to internalise. Anything non-ASCII costs more than one octet in UTF-8, so a `str` length and the length of its encoding are different numbers. Column limits, buffer sizes, database `VARCHAR` lengths and progress counters all have to say which of the two they mean. Both `str.encode()` and `bytes.decode()` default to UTF-8 when you omit the argument, and that default does not depend on the platform. Writing the encoding out anyway is still worth it: it documents the assumption at the point where it is made, and it survives the code being moved into a helper that reads from somewhere else. ## Why anything hands you bytes at all Octets are what actually travel and what actually persists. A socket read gives you `bytes` because the network moves octets and the peer's charset is not carried in the data itself — at best it is declared out of band, in an HTTP header or a file format's own header. A file opened with mode `"rb"` gives you `bytes` for the same reason: the disk stores octets. Hashing, compression and cryptographic signing all operate on octets, so those APIs take and return `bytes`. So every real program has a boundary, and the discipline is to make it explicit and thin: 1. Receive `bytes` at the edge. 2. Decode once, with an encoding you obtained or chose deliberately. 3. Do all business logic in `str`. 4. Encode once on the way out. The alternative — letting the two types travel together through the middle of an application — is where the classic bugs live: a value that is sometimes `str` and sometimes `bytes` depending on which code path produced it, and a `TypeError` or a mangled output that only appears for non-ASCII input, which is exactly the input your test fixtures never contain. ## Constructing each type `bytes` literals use a `b` prefix and may contain only ASCII characters plus `\xNN` escapes. You can build one from a list of integers with `bytes([104, 105])`, and `bytes(3)` gives three zero octets rather than the digit. `str(b"hi")` does *not* decode — it produces the string `"b'hi'"`, which is almost never what anyone wants; `b"hi".decode("utf-8")` is the real conversion. ## What an interviewer is checking They want to hear that you know the two types are not interchangeable, that conversion is always a codec operation, and that you have a rule for where in your program the conversion happens. Candidates who came from Python 2 sometimes still describe `str` as "bytes with characters in it"; that model was true in Python 2, where `str` was octets and `unicode` was text with implicit ASCII coercion between them, and it is the source of most confusion about this topic today.