PEP263 + exec statement

["Martin v. Löwis"]

Carlos Ribeiro wrote:
> It does not
> issue any warning when fed with arbitrary code that includes non-ASCII
> characters. I am not sure if this is:
> 
> 1) a design feature;
> 2) a bug on PEP 263 implementation;
> 3) a side effect of the fact that exec is not recommended anyway, and
> that it will probably be deprecated at some point.

It is rather

4) almost out of scope of PEP 263, which, in its first sentence,
    restricts itself to Python source *files*

There are a few places where Python source code is not stored
in files, namely:
- exec
- eval
- compile
- interactive mode
- IDLE shell

The PEP isn't really precise on what to do in these cases, it certainly
isn't fair to require an encoding declaration in all of them. In
particular, for interactive mode, it is undesirable to require such a
declaration. It is also unnecessary, since, in interactive mode, you
almost certainly know the encoding from sys.stdin.encoding.

So Python 2.4 will use sys.stdin.encoding for code entered in
interactive mode. My plan is that compile() grows an argument
to specify the encoding of the string, falling back to ASCII
if none is specified. Then, exec and eval would not need to
be modified - people who want to specify an encoding outside
of the source itself could pass a code object to exec or eval,
instead of directly passing the string to these constructs.
This would also take care of IDLE, which internally uses
compile().

I have implemented these changes, but I was a little bit too
late to submit them for Python 2.4.

Regards,
Martin