On Tue, Aug 19, 2014 at 7:03 PM, Terry Reedy <tjre...@udel.edu> wrote: > On 8/18/2014 7:44 PM, Chris Angelico wrote: >> Python 2.7.8 (default, Jun 30 2014, 16:03:49) [MSC v.1500 32 bit >> (Intel)] on win32 >> Type "copyright", "credits" or "license()" for more information. >>>>> >>>>> # -*- coding: utf-8 -*- > > > I don't think this has any lasting effect in interactive mode. Each > statement is compiled and executed separatedly. In Idle, this is done with > exec().
I didn't think it would, but wanted to cover all obvious possibilities before saying anything. >>>>> u"U+20AC is € is 0x80 in CP-1252" >> >> u'U+20AC is \x80 is 0x80 in CP-1252' > > > Better than what I get on my 3.4.1 Win7 > > U+20AC is € is 0x80 in CP-1252 How's \x80 better than an actual euro sign? (As ascii() shows, it's coming through as \u20ac, which is correct.) > The problem is python exec, not Idle. Use the editor and submit coding and > code together. There are two parts to the problem. Idle is interpreting my pasted text as CP-1252, but then the exec under the covers is defaulting to something else (Latin-1?). If exec were told to use 1252, then I think this would probably work (maybe?) - it'd be limited to a subset of Unicode characters, but it'd function. In theory, the encoding used between Idle's front-end and the back-end executor should be an implementation detail, nothing more - as long as they agree, all's well. I like interactive mode, it's a great way to test stuff quickly. And obviously, I do most of my work in 3.4, not 2.7, so this problem doesn't hit me. But when I need to test Py2 for something, I'd rather work interactively and iteratively than with the editor mode. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
