Python 交互式解释器在 Windows 上总是返回“无效语法”
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/4569858/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Python Interactive Interpreter always returns "Invalid syntax" on Windows
提问by user559217
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 with the code page of the prompt I run the interpreter from, but it doesn't seem to help at all.
我遇到了一个非常令人困惑的问题。无论我在 Python 解释器中输入什么，都会返回“无效语法”。请参阅下面的示例。我试过玩弄我运行解释器的提示的代码页，但它似乎根本没有帮助。
Furthermore, I haven't been able to find this particular, weird bug elsewhere online.
此外，我无法在网上的其他地方找到这个特殊的、奇怪的错误。
Any assistance anyone could provide would be lovely. I've already tried reinstalling Python, but I didn't have any luck - the problem is also there in both 3.13 and 2.7.
任何人都可以提供的任何帮助都会很可爱。我已经尝试重新安装 Python，但我没有任何运气 - 3.13 和 2.7 中也存在问题。
Running: Python version 3.1.3, Windows XP SP3.
运行：Python 3.1.3 版，Windows XP SP3。
Getting:
获得：
C:\Program Files\Python31>.\python
Python 3.1.3 (r313:86834, Nov 27 2010, 18:30:53) [MSC v.1500 32 bit (Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> 2+2
File "<stdin>", line 1
2+2
^
SyntaxError: invalid syntax
>>> x = "Oh, fiddlesticks."
File "<stdin>", line 1
x = "Oh, fiddlesticks."
^
SyntaxError: invalid syntax
回答by Paul B
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
以交互方式和无缓冲方式运行 Python 时存在一个已知问题，该问题计划在 3.2 中修复 - 并且可能会向后移植到旧版本，请参阅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 alwaysrun 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.
令人讨厌的是，人们可能在没有意识到的情况下使用了无缓冲 I/O。在我的情况下（Python 2.5.4 (r254:67916)），我前段时间设置了一个环境变量，这样 Python 将始终无缓冲地运行（在 Windows 上，这是 PYTHONUNBUFFERED=YES，或者任何替代 YES 的非空字符串）然后忘记了。删除 env.var。为我解决了这个问题。
So it may be worthwhile checking for this environment variable. It's not set by default.
所以检查这个环境变量可能是值得的。它不是默认设置的。
回答by Duncan
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.pycontaining this code, run it, and then type in some text?:
这不是解决方案，但是如果您创建一个t.py包含此代码的文件，运行它，然后输入一些文本，会发生什么？：
import sys; print(repr(sys.stdin.readline()))
If you type something like 2+2then 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.
如果您输入类似2+2then 的内容，那么幸运的话这将向您显示 Python 解释器在您的示例中得到的内容，而这反过来可能会为问题提供一些线索。
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.
这将允许您键入一行并显示该行的详细信息。
回答by John Machin
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"
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:\Python31which 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".
最好是将它放在“程序文件”之外。除非我记错了，否则建议的安装文件夹会C:\Python31很好，因为您不需要像使用“程序文件”时那样的引号。AFAIK 没有充分理由在“程序文件”中安装软件。
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.
A. 打开命令提示符窗口。
B. 输入：dir "c:\program files\python31"
C. 将步骤 B 的结果复制/粘贴到您的问题的编辑中，即不要将其放入评论中。
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?
如果您回答了（在您的问题的编辑中）有人问到的有关键盘宏的问题，那会有所帮助……还要考虑过度智能键盘的可能性，以及拥有多个 IME 而没有使用“正确”的输入法的可能性。另外，除了 Python 之外的任何软件都会发生这种行为吗？
回答by Lennart Regebro
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.
有一次，在 2002 年，我设法构建了一个无法使用 Windows 行尾运行的 Python 版本。它会给出这样的语法错误，指向行尾。我发现这极不可能在这种情况下成为问题，特别是因为您使用的是 Windows 安装。
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.
当我无意中使用不间断空格而不仅仅是空格时，我也遇到了类似的问题，但我没有看到提示中会发生这种情况，此外，2+2 示例不使用空格或引号，这也可以成为问题。
What encodings and keyboard settings are you using?
您使用的是什么编码和键盘设置？
回答by Fruit
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 vimthe history file (or you might consider hexdump -Cin case vimdoesn't shows the hidden characters):
我通过vim历史文件找出原因（或者您可能会考虑hexdump -C，以防vim不显示隐藏字符）：
According to http://www.w3.org/International/questions/qa-bidi-controls:
根据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
RLM 和 LRM 字符
Unicode 提供的另外两个不可见但非嵌入的方向控制字符通常没有相应的标记，应以字符或转义形式使用。请注意，它们的问题较少，因为它们是单独使用的，而不是像我们讨论过的其他控制字符那样成对使用来分隔文本范围。
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.
原因是因为我直接从包含隐藏的 RLM 和 LRM 字符的在线代码（我知道它在安全方面很危险）中直接复制/粘贴。
