Python 2.7 IDLE Win32 interactive, pasted characters i- wrong encoding

[Chris Angelico]

On Tue, Aug 19, 2014 at 7:03 PM, Terry Reedy <tjreedy at 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