在Python中，每个字符串都包含空字符串。

answer = input("Enter 'Y[es] or N[o]:")
if answer in 'YyNn':        # verify input
    process(answer) 

只要在上面的查询中点击return就会将答案设置为空字符串，将if答案传递给…测试，并被处理为正确答案。更简洁地说:

>>> "ABCDEFGHIJ".__contains__("")
True

像往常一样，Python在这里的行为在数学和逻辑上都是无可挑剔的。就像我在很久以前的集合论课上回忆的那样:空集合是每个集合的成员。

当我偶尔被它咬到的时候，它仍然让我感到惊讶，但我不会有其他的方式。

X = X + 1

当我还是初学者的时候，这很难消化，而现在函数式语言不使用它了，这就更难了!

如果你不明白这有多奇怪:把等号看作断言语句，而不是赋值操作，就像你在基础代数中经常做的那样，那么这相当于说“0 = 1”。

大约20年前，我用一个编译器为一种叫做Coral的语言工作，它允许我声明只写变量!

不过，这是有道理的，因为它们是全球性的，被用作一种信号机制。一个进程写入值，另一个进程读取值。

在fortran中(当然是77，可能在95中也是如此)，未声明的变量和以I到N开头的参数(“In”组)将是INTEGER，所有其他未声明的变量和参数将是REAL(源)。这与“在某些情况下可选的空白”相结合，导致了最著名的错误之一。

正如弗雷德·韦伯在1990年的《另类民间传说:计算机》一书中所说:

I worked at Nasa during the summer of 1963. The group I was working in was doing preliminary work on the Mission Control Center computer systems and programs. My office mate had the job of testing out an orbit computation program which had been used during the Mercury flights. Running some test data with known answers through it, he was getting answers that were close, but not accurate enough. So, he started looking for numerical problems in the algorithm, checking to make sure his tests data was really correct, etc. After a couple of weeks with no results, he came across a DO statement, in the form: DO 10 I=1.10 This statement was interpreted by the compiler (correctly) as: DO10I = 1.10 The programmer had clearly intended: DO 10 I = 1, 10 After changing the . to a , the program results were correct to the desired accuracy. Apparently, the program's answers had been "good enough" for the sub-orbital Mercury flights, so no one suspected a bug until they tried to get greater accuracy, in anticipation of later orbital and moon flights. As far as I know, this particular bug was never blamed for any actual failure of a space flight, but the other details here seem close enough that I'm sure this incident is the source of the DO story.

我认为这是一个很大的WTF，如果DO10I被作为DO10I，并且反过来，因为隐式声明被认为是类型REAL。这是个很棒的故事。

这让我惊艳

#define _ -F<00||--F-OO--;
int F=00,OO=00;main(){F_OO();printf("%1.3f\n",4.*-F/OO/OO);}F_OO()
{
            _-_-_-_
       _-_-_-_-_-_-_-_-_
    _-_-_-_-_-_-_-_-_-_-_-_
  _-_-_-_-_-_-_-_-_-_-_-_-_-_
 _-_-_-_-_-_-_-_-_-_-_-_-_-_-_
 _-_-_-_-_-_-_-_-_-_-_-_-_-_-_
-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
 _-_-_-_-_-_-_-_-_-_-_-_-_-_-_
 _-_-_-_-_-_-_-_-_-_-_-_-_-_-_
  _-_-_-_-_-_-_-_-_-_-_-_-_-_
    _-_-_-_-_-_-_-_-_-_-_-_
       _-_-_-_-_-_-_-_
           _-_-_-_
}

在统一中,

GameObject.Find("MyObject")

将正常返回对象。然而，如果你这样做:

GameObject.Find("MyObject").active = false;
//do other stuff
if (GameObject.Find("MyObject").active)
{
    //do stuff
}

然后您将得到一个空引用。在Unity iPhone中，这段代码通常在编辑器中正常工作，但在iPhone上运行时会导致SIGBUS。问题是GameObject.Find()将只定位活动对象，所以即使你只是检查它是否活动，你也会有效地调用if (null.active)。

为了使它正常工作，你必须在使它不活跃之前存储它。

GameObject obj = GameObject.Find("MyObject");
obj.active = false;
//do other stuff
if (obj.active)
{
    //do stuff
}

可以说，这是一种更好的实践，但Unity处理非活动对象的方式通常是相当奇怪的。它似乎卸载了大部分非活动对象(纹理等)，但不是全部，因此非活动对象仍然会消耗大量内存。