The bytes/str dichotomy in Python 3
January 30th, 2012 at 7:48 pmArguably the most significant new feature of Python 3 is a much cleaner separation between text and binary data. Text is always Unicode and is represented by the str type, and binary data is represented by the bytes type. What makes the separation particularly clean is that str and bytes can’t be mixed in Python 3 in any implicit way. You can’t concatenate them, look for one inside another, and generally pass one to a function that expects the other. This is a good thing.
However, boundaries between strings and bytes are inevitable, and this is where the following diagram is always important to keep in mind:
Strings can be encoded to bytes, and bytes can be decoded back to strings.
>>> '€20'.encode('utf-8')
b'\xe2\x82\xac20'
>>> b'\xe2\x82\xac20'.decode('utf-8')
'€20'
Think of it this way: a string is an abstract representation of text. A string consists of characters, which are also abstract entities not tied to any particular binary representation. When manipulating strings, we’re living in blissful ignorance. We can split and slice them, concatenate and search inside them. We don’t care how they are represented internally and how many bytes it takes to hold each character in them. We only start caring about this when encoding strings into bytes (for example, in order to send them over a communication channel), or decoding strings from bytes (for the other direction).
The argument given to encode and decode is the encoding (or codec). The encoding is a way to represent abstract characters in binary data. There are many possible encodings. UTF-8, shown above, is one. Here’s another:
>>> '€20'.encode('iso-8859-15')
b'\xa420'
>>> b'\xa420'.decode('iso-8859-15')
'€20'
The encoding is a crucial part of this translation process. Without the encoding, the bytes object b'\xa420' is just a bunch of bits. The encoding gives it meaning. Using a different encoding, this bunch of bits can have a different meaning:
>>> b'\xa420'.decode('windows-1255')
'₪20'
That’s 80% of the money lost due to using the wrong encoding, so be careful 
Related posts:
January 31st, 2012 at 06:57
Nice summary. One minor technicality: Python 3 strings are a sequence of code points rather than characters. While those are effectively the same thing for most text processing, they aren’t *exactly* the same thing in the Unicode standard.
January 31st, 2012 at 07:54
Nick,
Thanks for the clarification. I was actually planning to write a more in-depth article on Unicode with Python 3 at some point (because I couldn’t really find something that was good enough online). Maybe I’ll get to it one day…
January 31st, 2012 at 12:29
Quick and neat. I like the diagram too. Thx.
January 31st, 2012 at 14:19
AIUI this is complicated by the fact that Python compiled in UCS2 mode will only use code points that are represented by a single utf16 code unit, using surrogate pairs for the astral plane. This applies to windows builds of CPython, and on Linux, to non-distribution builds of CPython (due to a questionable configure default); I believe this will be fixed by PEP 393 in Python 3.3.
January 31st, 2012 at 14:29
Tobu,
Thanks to your comment I’ve just learned a new acronym – AIUI
January 31st, 2012 at 17:27
I like to think of encoding of strings to the analogy of encrypting your plain text into a random stream of bytes
string (plain text) -> encode (encrypt) -> bytes (stream)
bytes (stream) -> decode (decrypt) -> string (plain text)
and the codec you choose is your key (utf-8 …)
January 31st, 2012 at 22:33
Since I have started using Python 3, I do not understand strings in Python 2 anymore. :-/
February 1st, 2012 at 10:25
I found the chapter on Unicode in DiveIntoPython3 excellent. Have you read it?
February 1st, 2012 at 17:21
encode()/decode() is confusing/misleading/hard to remember.
tobytes()/frombytes() would be more clear.
February 1st, 2012 at 18:54
anatoly,
I’d argue this is a matter of preference. Personally I find
encode / decodeclearer.March 27th, 2012 at 15:48
This is a good change. People far too often don’t appreciate the difference between text and bytes. Especially, I am afraid, americans who live far from Europe and only use ASCII themselves.
In more recently designed frameworks such as .NET, there is a the same distinction, and you go through either encodings or, more usual, TextReader/Writers, to read/write text into various byte streams (such as files).
I’ve unfortunately spent too many hours arguing with people about the need to handle this correctly in open source software I am involved in.
March 28th, 2012 at 17:47
encode()/decode() makes more sense because of the parameters you can pass in for the different types of encoding schemes. If it was tobytes()/frombytes() that would suggest that there was a single standard byte representation for a given string which is not the case.