Chris Angelico wrote: > On Fri, Nov 21, 2014 at 3:32 AM, Peter Otten <__pete...@web.de> wrote: >> Chris Angelico wrote: >> >>> On Fri, Nov 21, 2014 at 2:40 AM, Peter Otten <__pete...@web.de> wrote: >>>> I think that you may get a Unicode/Encode/Error when you try to >>>> /decode/ a unicode string is more confusing... >>> >>> Hang on a minute, what does it even mean to decode a Unicode string? >> >> Let's not get philosophical ;) > > No, I'm quite serious.
I'm sorry I'm limited to text, otherwise I would have formatted the ";)" as 30pt blinking magenta... > You encode Unicode text into bytes; you decode > bytes into text. You can also encode a floating-point value into > bytes, and decode bytes into a float. Or you could encode a large and > complex structure into bytes, using something like pickle or json, and > then decode those bytes later on. The pattern is always the same: the > abstract object with meaning to a human is encoded into a concrete > form that a computer can handle, and the concrete is decoded into the > abstract. If you're not good at sight-reading sheet music, you'll have > the same feeling of staring at the dots, decoding them one by one into > this abstract thing called "music", and then being able to work with > it. > > When you try to decode a Unicode string, what happens is that Python 2 > says "Oh, you're trying to do a byte-string operation on a Unicode > string... I'll quickly encode that to bytes for you, then do what you > asked". That's why you can get an *en*coding error when you asked to > *de*code - because both operations have to happen. In an alternative universe unicode.decode() could have been implemented as a no-op. As you put it it looks like you have to find the true nature of the problem and then cast it into code -- a kind of essentialism. I would rather emphasise the process; the evolving interface changes your view on the underlying problem -- a hermeneutic cycle if you will. -- https://mail.python.org/mailman/listinfo/python-list
