"3.1.3 Unicode Strings" contains: >>> u"äöü" u'\xe4\xf6\xfc' It looks like latin1 is used as encoding for this Unicode literal. This is, however, neither justified by the Python language specification nor by common sense ;-) I'd suggest that this be changed in the tutorial. Furthermore I'd suggest that such use of Unicode literals throw errors instead. I'm assigning it to Martin, because he's one of the Unicode gurus :)
Logged In: YES user_id=163326 I *do* get the warnings when executing scripts, but I do *not* get the warnings at the interactive prompt. Lowering priority accordingly. Feel free to close this if this is indeed the intended behaviour.
Logged In: YES user_id=163326 Oh, I almost forgot about my original problem. Such behaviour shouldn't be encouraged in the tutorial any longer of course. Maybe I can find a better wording and submit a patch soonish. Now that I understand this better, assignnig this to myself :)
Logged In: YES user_id=21627 The intended behaviour is that Unicode in the interactive mode "works", and assumes that the actual input is encoded according to the locale's encoding (i.e. sys.stdin.encoding). That isn't implemented, yet (and perhaps not even specified). However, it is most likely the case that this is a doc bug in ref manual, not in the tutorial. For this to work, the interactive mode needs to be able to pass the encoding to the parser, perhaps giving a Unicode object as the argument instead of a byte string (atleast IDLE might want to do that). Passing Unicode objects to eval/exec is for further study, though.
Logged In: YES user_id=163326 I just read PEP 0263, which says: """ In Python 2.1, Unicode literals can only be written using the Latin-1 based encoding "unicode-escape". """ So the tutorial is correct and the things Martin suggested are only possible improvements to Python, there's no actual bug here. So I'll close this one.
