【题目致敬JavaScript（一种编程语言）经典：《JavaScript: The Good Parts》（《JavaScript语言精粹》）】
无疑，《疯狂动物城》是一部伟大的作品。
你可以用任何喜欢的赞美之辞来描述它，诸如制作精良、剧情完整、寓意深刻、想象丰富等等，然而赞美往往千篇一律，简单而无趣。本文尝试从其表达的内涵出发，以不一样的视角来分析这部电影。题目中的 "The Bad Parts" 不一定指电影的瑕疵，更多是指其内涵体现出的现实的暗黑面。
作为迪士尼出品的一部动画片，其实电影并没有太多太搞笑的部分，尤其是无厘头式的搞笑更是没有。而在幽默层面上对影片贡献最大的片段，无疑是封面图片上“找树懒查车辆记录”这个桥段。利用树懒行动超级迟缓的特点，影片在此制造了可以让观众爆笑的笑点。把这个桥段放回电影整体，我们可以看出电影基本上就是用动物世界里巨大的反差来抓眼球和制造笑料的。大小之间的反差，快慢之间的反差，总之因为动物们千奇百怪却又同住一城，所以影片利用这个方面来制造笑料，这样确实可以产生事半功倍的效果，逻辑上也很自然。
不过，正是因为这一点，戏里戏外，一个更暗黑的现实却浮现了出来。
电影主旨的基本落脚点在偏见与歧视上，但电影本身却采用了大量迎合观众“刻板印象”的表现方式，来制造“反差萌”和“幽默点”。兔子就应该生一窝、树懒就一定慢到不行（即便真的是为了讽刺办事人员效率低下）、所有猛兽的配音都是雄性等等。当然，这不应该算作是电影内核的一个矛盾，作为兼具艺术性和商业性的电影来说，迎合观众的口味与想象（或者说“刻板印象”）是其想要达到的目标之一，而反差和夸张，能更好地增强其表现力。
这不禁让我想起了这么一回事儿。学习过 Python（一种编程语言）的大多知道，使用 "import this" 命令会输出一首小诗，名字叫《The Zen Of Python》（见附一），可译为“ Python 之道”或者“ Python 禅道”都可，其主要表达的就是 Python 崇尚的一些类似软件工程价值观层面的东西，譬如代码要简洁易读等等，然而如果你去看 this 模块的源代码，却可以发现这个模块的源代码（见附二）几乎违背了所有它所崇尚的东西。这段源码故意用凯撒加密的方式（每个字符的值往后移13位）来打印《The Zen Of Python》，至少就已经违反了“Simple is better than complex. ”这条“禅道”。当然，这应该只是 this.py 的作者作为程序员故意开的一个玩笑。
回到主题，《疯狂动物城》用“贴标签”增强表现力来反对“贴标签”，其实正是说明了，偏见就跟优越感一样，它无处不在。this.py 的作者半开玩笑之中其实也带着某种偏见。《The Zen Of Python》着力强调编码工作应该变得简洁优雅，这也正是 Python 的设计之道，然而作者依然用难以阅读的方式书写了这段源码，这莫不是一种对编程“奇技淫巧”的偏见。偏见无处不在，每个人都或多或少对某些事物带着偏见，这从一个侧面佐证了大众的愚昧。你，我，都是这愚昧大众中的一员。
偏见就跟优越感一样，它无处不在，但当它表现出不好的一面时，往往比优越感更伤人。当然，个人的偏见并不可怕，它甚至在某个正面就转化成了“经验”，随着年龄增长“偏见”可能还越来越深，帮你在这纷繁冗杂的世界里快速筛选出自己想要的东西。然而群体性的偏见却不容小视，种族歧视和性别歧视便是当今世界最现实的表现。
最后，花费睡觉时间在这里开脑洞乱扯，我只是简单地希望像对待优越感一样，更多人能够正视内心的偏见，唯有更好的认识才能更好的控制。
晚安，愿每个人都能在这残忍又愚昧的世界里找到属于自己的“温柔以待”。
附一：
The Zen of Python, by Tim Peters
Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one -- and preferably only one -- obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than right now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!
附二：
Python Lib库，this.py源码：
s = """Gur Mra bs Clguba, ol Gvz Crgref
Ornhgvshy vf orggre guna htyl.
Rkcyvpvg vf orggre guna vzcyvpvg.
Fvzcyr vf orggre guna pbzcyrk.
Pbzcyrk vf orggre guna pbzcyvpngrq.
Syng vf orggre guna arfgrq.
Fcnefr vf orggre guna qrafr.
Ernqnovyvgl pbhagf.
Fcrpvny pnfrf nera'g fcrpvny rabhtu gb oernx gur ehyrf.
Nygubhtu cenpgvpnyvgl orngf chevgl.
Reebef fubhyq arire cnff fvyragyl.
Hayrff rkcyvpvgyl fvyraprq.
Va gur snpr bs nzovthvgl, ershfr gur grzcgngvba gb thrff.
Gurer fubhyq or bar-- naq cersrenoyl bayl bar --boivbhf jnl gb qb vg.
Nygubhtu gung jnl znl abg or boivbhf ng svefg hayrff lbh'er Qhgpu.
Abj vf orggre guna arire.
Nygubhtu arire vf bsgra orggre guna evtug abj.
Vs gur vzcyrzragngvba vf uneq gb rkcynva, vg'f n onq vqrn.
Vs gur vzcyrzragngvba vf rnfl gb rkcynva, vg znl or n tbbq vqrn.
Anzrfcnprf ner bar ubaxvat terng vqrn -- yrg'f qb zber bs gubfr!"""
d = {}
for c in (65, 97):
for i in range(26):
d[chr(i+c)] = chr((i+13) % 26 + c)
print("".join([d.get(c, c) for c in s]))
