Drekin / win-unicode-console

A Python package to enable Unicode support when running Python from Windows console.
MIT License
103 stars 12 forks source link

execfile() rejects valid Python 2 #14

Closed osvenskan closed 8 years ago

osvenskan commented 8 years ago

Thanks for the Python 2 support and the module in general!

I'm seeing a problem when launching a Python 2 script with the runner.

I have win-unicode-console installed as a Python patch in sitecustomize.py. I only have 1 Python installed, and it's Python 2.

I have a simple Python 2 script called foo.py which contains this:

print "hello world"

According to the documentation, I should be able to temporarily disable win-unicode-console for my script by running it this way:

python -m run --init-disable foo.py

However, when I do so, I get this:

  File "foo.py", line 1
    print "hello world"
                      ^
SyntaxError: invalid syntax

The error disappears if I change foo.py to contain this (which is also valid Python 2):

print("hello world")

My guess is that the from __future__ import print_function in runner.py is leaking through to modules run via the execfile call.

Drekin commented 8 years ago

Thank you for the report. Your explanation makes sense. It is unfortunate that it is so non-trivial to write a transparent runner. The following also doesn't work.

from __future__ import print_function
exec('print "hello world"')

There is a parameter dont_inherit to compile function that should prevent the leaking. If I remember, I use execfile in Python 2 instead of compile and exec, because there is no tokenize.open in Python 2 (it reads a source code as a string using the encoding cookie if present).

I'll look at it when I have time.

qntm commented 8 years ago

Is it not possible to just eliminate that from __future__ import print_function call entirely? At first glance it seems that the only reason it's needed is so we can call print(line, file=file, end="") a little later in runner.py. Can't this be replaced with something else?

Drekin commented 8 years ago

@ferno That would just mask the fact that the runner is currently not transparent to the used __future__ flags. The correct solution is described above, I just haven't find time to actually implement it. If you are suffering from this issue, I'll try to find some time in the near future.

Drekin commented 8 years ago

This should be now fixed, try the development version.

osvenskan commented 8 years ago

Sorry I didn't get a chance to test this. I'm no longer working with the client that required this code. Thanks for the fix!