Python Interactive Interpreter always returns “Invalid syntax” on Windows

前端 未结 5 1574
迷失自我
迷失自我 2020-12-16 04:23

I\'ve encountered an extremely confusing problem. Whatever I type into the Python interpreter returns \"Invalid Syntax\". See examples below. I\'ve tried fooling around w

相关标签:
5条回答
  • 2020-12-16 05:05

    There is a known problem when running Python interactively and unbuffered, which is scheduled for fixing in 3.2 - and may be backported to older versions, see http://bugs.python.org/issue11098

    The nasty thing is, one may be using unbuffered I/O without realising it. In my case (Python 2.5.4 (r254:67916)), I had some time ago set an environment variable such that Python would always run unbuffered (on Windows, this is PYTHONUNBUFFERED=YES, or whatever non-empty string substituted for YES) and then forgot about it. Removing the env.var. solved the problem for me.

    So it may be worthwhile checking for this environment variable. It's not set by default.

    0 讨论(0)
  • 2020-12-16 05:05

    Once, in like 2002, I managed to build a version of Python who couldn't run with Windows line-ending. It would give syntax errors like this, pointing at the end of the line. I find this highly unlikely that it is a problem in this case though, especially since you are using the Windows install.

    I also had similar problems when I was inadvertently using non-breaking spaces instead of just spaces, but I don't see how that would happen from the prompt, and besides you 2+2 example doesn't use spaces nor quotes which also could be a problem.

    What encodings and keyboard settings are you using?

    0 讨论(0)
  • 2020-12-16 05:08

    Now that the sample has been cleaned up it appears the problem is with the line termination.

    This isn't a solution, but what happens if you create a file t.py containing this code, run it, and then type in some text?:

    import sys; print(repr(sys.stdin.readline()))
    

    If you type something like 2+2 then with luck this will show you what the Python interpreter is getting in your example and that in turn might give some clue to the problem.

    You can also try this at the command prompt:

    python -c "import sys; print(repr(sys.stdin.readline()))"
    

    This will allow you to type one line and display the details of that one line.

    0 讨论(0)
  • 2020-12-16 05:08

    This is a worry:

    C:\Program Files\Python31>.\python
    

    It is never a very good idea to run software with the current directory set to the software installation directory. You run the risk of creating files that interfere with the running of the software. When you start getting bugs and weird behaviour, the consequent thrashing about can get the situation completely out of control.

    This is better:

    C:\somewhere_else_with_no_spaces>"c:\program files\python31\python"

    Best is to keep it out of "program files". Unless I'm misremembering, the suggested installation folder would be C:\Python31 which is good because you don't need the quotes like you do whenever you use "program files". There is AFAIK no good reason for having software in "program files".

    Some diagnostics:

    A. open up a Command Prompt window.
    B. type this: dir "c:\program files\python31"
    C. copy/paste the result from step B into an edit of your question i.e. don't put it in a comment.

    It would help if you answered (in an edit of your question) the question that somebody asked about keyboard macros ... also consider the possibility of over-smart keyboards, and of having multiple IMEs and not using the "correct" one. Also, is this behaviour happening with any software other than Python?

    0 讨论(0)
  • 2020-12-16 05:15

    I face the same problem even though it might not the same like you, but there's alternative way to diagnostic, you should always set up a history file.

    I find out the reason by vim the history file (or you might consider hexdump -C in case vim doesn't shows the hidden characters):

    According to http://www.w3.org/International/questions/qa-bidi-controls :

    RLM and LRM characters

    Two other invisible but non-embedding directional control characters provided by Unicode do not usually have corresponding markup and should be used either in character or escaped form. Note that they are less problematic because they are used singly, not in pairs to delimit ranges of text like the other control characters we have discussed.

    U+200E:   LEFT-TO-RIGHT MARK
    U+200F:   RIGHT-TO-LEFT MARK
    

    The reason is because i direct copy/paste from online code(i know it's dangerous in security though) which contains hidden RLM and LRM characters.

    0 讨论(0)
提交回复
热议问题