我一直在研究将 python(OSX 上的 2.7)文件作为配置文件加载的一些特殊情况。如果我循环运行 execfile,我想看看行为是什么。我预计会发生内存不足错误或大量交换,但当我得到不同的结果时,我感到非常惊讶。
我设置了一个测试场景如下:
'd' python 脚本:
#!/usr/bin/python
x = 0
execfile("d1")
'd1' python 脚本:
#!/usr/bin/python
x += 1
print "x = %d" % x
execfile("d2")
'd2' python 脚本:
#!/usr/bin/python
x += 1
print "x = %d" % x
execfile("d1")
结果:
$ ./d
x = 1
x = 2
x = 3
... removed for brevity ...
x = 997
x = 998
x = 999
Traceback (most recent call last):
File "./d", line 5, in <module>
execfile("d1")
File "d1", line 5, in <module>
execfile("d2")
File "d2", line 5, in <module>
execfile("d1")
... removed for brevity ...
File "d1", line 5, in <module>
execfile("d2")
File "d2", line 5, in <module>
execfile("d1")
File "d1", line 5, in <module>
execfile("d2")
KeyError: 'unknown symbol table entry'
我很好奇是否有人可以解释这里发生的事情?为什么执行execfile~1000次就停止了?
最佳答案
来自 Python 源代码,Objects/dictobject.c
:
/* Note that, for historical reasons, PyDict_GetItem() suppresses all errors * that may occur (originally dicts supported only string keys, and exceptions * weren't possible). So, while the original intent was that a NULL return * meant the key wasn't present, in reality it can mean that, or that an error * (suppressed) occurred while computing the key's hash, or that some error * (suppressed) occurred when comparing keys in the dict's internal probe * sequence. A nasty example of the latter is when a Python-coded comparison * function hits a stack-depth error, which can cause this to return NULL * even if the key is present. */
So, PyDict_GetItem()
does not always report errors correctly. Interesting... so in the following code in Python/symtable.c
,
v = PyDict_GetItem(st->st_blocks, k);
if (v) {
assert(PySTEntry_Check(v));
Py_INCREF(v);
}
else {
PyErr_SetString(PyExc_KeyError,
"unknown symbol table entry");
}
查找符号时发生的任何错误(包括内存不足错误)都将变成KeyError
。这可能是一个错误。
关于python - 符号表的限制?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/19613489/