The confusion you're talking about is a Python 2 problem, not one of ambiguity. Encoding and decoding are pretty well defined (though, I've never thought about

The confusion you're talking about is a Python 2 problem, not one of ambiguity. Encoding and decoding are pretty well defined (though, I've never thought about the formal definition before). When you have an entity in its native form, it needs to be _encoded_ for the purposes of communication (in a broad sense). The encoded message can then be to be _decoded_ back to the natural form. There is no ambiguity. Really, the reason people get them mixed up in Python is because Python 2 totally stacked it by adding str.encode and unicode.decode. In Python 2, you can _decode_ unicode to unicode – which it does by silently _encoding_ as ascii first. This operation is total madness. >>> u = u'\xe9' >>> u.decode('utf8') Traceback (most recent call last): File "<stdin>", line 1, in <module> UnicodeEncodeError: 'ascii' codec can't encode character u'\xe9' in position 0: ordinal not in range(128) The error here is in the step where you _encode_ the unicode to acsii, something you didn't ask it to do at all. And similarly, you can encode str to str (where str is really bytes in Python 2, another issue that adds to the confusion). Don't get me wrong. I feel your pain. When I was using Python 2 I also got confused about what form things were in and where I needed to encode / decode. Honestly, once I switched to Python 3, that cognitive overhead just totally vanished. str is the natural form of text, and if I need to store / communicate it I _encode_ it to bytes (utf8, generally). When I'm loading a stored/transmitted message, I _decode_ it to its natural text form. There are edge cases that make certain situations more complex, but in terms of general usage, I feel Python 3 really got this stuff right.