Python能让你上天?带你挖掘隐藏彩蛋~(附代码)

本文将带你挖掘Python中隐藏的彩蛋。

Python当然能让你上天!

没试过?别担心,我来教你。和Python里的其他东西一样,它非常简单。你只需要敲入下面这行反重力代码

import antigravity

这是啥?

这是个彩蛋。import antigravity将打开一个指向经典XKCD漫画的网页(source:https://xkcd.com/353/),里面提到了Python。你知道吗,开发者并没有止步于此,彩蛋里还有一个彩蛋。

如果你查看代码(source:https://github.com/python/cpython/blob/master/Lib/antigravity.py#L7-L17),你会看到一个函数定义用来实现XKCD’s的geohashing算法(source:https://xkcd.com/426/)。

还有类似的彩蛋吗?

当然!我在网上找到了更多的彩蛋:

1. Python的禅宗

在命令行中输入:

import this

即可获得 Tim Peters 的《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之禅 赖勇浩翻译   优美胜于丑陋(Python 以编写优美的代码为目标)   明了胜于晦涩(优美的代码应当是明了的,命名规范,风格相似)   简洁胜于复杂(优美的代码应当是简洁的,不要有复杂的内部实现)   复杂胜于凌乱(如果复杂不可避免,那代码间也不能有难懂的关系,要保持接口简洁)   扁平胜于嵌套(优美的代码应当是扁平的,不能有太多的嵌套)   间隔胜于紧凑(优美的代码有适当的间隔,不要奢望一行代码解决问题)   可读性很重要(优美的代码是可读的)   即便假借特例的实用性之名,也不可违背这些规则(这些规则至高无上)   不要包容所有错误,除非你确定需要这样做(精准地捕获异常,不写 except:pass 风格的代码)   当存在多种可能,不要尝试去猜测   而是尽量找一种,最好是唯一一种明显的解决方案(如果不确定,就用穷举法)   虽然这并不容易,因为你不是 Python 之父(这里的 Dutch 是指 Guido )   做也许好过不做,但不假思索就动手还不如不做(动手之前要细思量)   如果你无法向人描述你的方案,那肯定不是一个好方案;反之亦然(方案测评标准)   命名空间是一种绝妙的理念,我们应当多加利用(倡导与号召)

2. Python知道爱是复杂的

>>> love = this >>> this is love True >>> love is True False >>> love is False False >>> love is not True or False True >>> love is not True or False; love is love # Love is complicated True

Python中的this模块是Python禅宗(PEP 20)(source:https://www.python.org/dev/peps/pep-0020/) 中的一个彩蛋。有趣吧?你可以看看this.py(source:https://hg.python.org/cpython/file/c3896275c0f6/Lib/this.py)中的具体实现。

有趣的是,禅宗的代码是自相矛盾的(这可能是Python里唯一发生这种情况的地方)。爱不是真或假,爱就是爱这句话读起来有点讽刺,却不言自明。

3. 花括号的使用

如果你不喜欢在Python中使用空格来表示作用域,想使用C风格的花括号{},你试着导入:

from__future__ importbraces

然后你会得到:

File "some_file.py", line 1 from __future__ import braces SyntaxError: not a chance

__future__模块通常用来提供Python未来版本的一些功能。这里“未来”对“花括号”做了小小的讽刺:想都别想!这是Python社区对这个问题的彩蛋。

4. “Hello world”程序可以有多简单?

够简单了吧:

>>> import __hello__ Hello World!

5. 来认识“亲切大叔”(Friendly Language Uncle For Life)

>>>from__future__ importbarry_as_FLUFL >>> "Ruby"!= "Python"# there's no doubt about it File"some_file.py", line 1 "Ruby"!= "Python" ^ SyntaxError: invalid syntax

>>> "Ruby"<> "Python" True

欧了。

这个彩蛋与2009年4月1日发布的PEP-401有关(401,你懂得)。鉴于Python3.0里的不!=是一个糟糕的损耗程序员手指的存在,BDFL的并不存在的继任者FLUFL又将其改回去了。更多彩蛋见(source:https://www.python.org/dev/peps/pep-0401/)。

译者注:BDFL(Benevolent Dictator For Life)直译为“仁慈的独裁者”,指Python的发明者Guido van Rossum在Python开发上享有监管权和决定权。2009年的愚人节,Guido宣布退休并任命Barry Warsaw为继任者,继任者的正式头衔是“亲切大叔(Friendly Language Uncle For Life,FLUFL)”,FLUFL立刻公布了一个PEP文档(Python编码规范文档),其中之一就是将不等号运算符!=重新规定为旧运算符<>。本文将其作为Python彩蛋。

6. 无穷大

Python中的拼写是有目的的。

>>> infinity = float('infinity') >>> hash(infinity) 314159 >>> hash(float('-inf')) -314159

在Python中,无穷大的hash是105×π。有趣的是, float(“-inf”)的hash在Python 3版本里是“-105×π”而在Python 2版本里是“-105×e”。

还想看更多彩蛋?

我已经花了好几个月的时间来挖掘Python里的这些神奇彩蛋。

我推荐你看 What the f*ck Python?(source:https://github.com/satwikkansal/wtfpython)Python里的各种微妙而复杂的代码片段。

原文标题:Can Python Make You fly?

原文链接:

https://www.codementor.io/satwikkansal/can-python-make-you-fly-fuolx8uxu

译者简介

王婷,南京理工大学在读研究生,爱笑得有眼角鱼尾纹的运气不赖的女生。不喜欢呆板、教条、无聊,喜欢接触新事物,参加新活动,融入新环境,结交新朋友,互相学习,取长补短。

翻译组招募信息

工作内容:需要一颗细致的心,将选取好的外文文章翻译成流畅的中文。如果你是数据科学/统计学/计算机类的留学生,或在海外从事相关工作,或对自己外语水平有信心的朋友欢迎加入翻译小组。

你能得到:定期的翻译培训提高志愿者的翻译水平,提高对于数据科学前沿的认知,海外的朋友可以和国内技术应用发展保持联系,THU数据派产学研的背景为志愿者带来好的发展机遇。

其他福利:来自于名企的数据科学工作者,北大清华以及海外等名校学生他们都将成为你在翻译小组的伙伴。

原文发布于微信公众号 - 数据派THU(DatapiTHU)

原文发表时间:2018-04-23

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏程序员宝库

【收藏】如何准备Java初级和高级的技术面试

本人最近几年一直在做java后端方面的技术面试官,而在最近两周,又密集了面试了一些java初级和高级开发的候选人,在面试过程中,我自认为比较慎重,遇到问题回答不...

812
来自专栏企鹅号快讯

程序员的花样编程,你到底行不行?

【导读】:说到 C/C++ 代码技巧,也许会有童鞋说 ,这是属于 C/C++ 程序员离职前恶搞之类的抖机灵。即便想,也不能干。别忘了有这样一句编程名言:「在编写...

2015
来自专栏木东居士的专栏

程序员该如何管理后宫:和女生沟通的艺术(装饰模式)

1926
来自专栏腾讯NEXT学位

人人都是艺术家!谈谈那些奇怪的字符

3587
来自专栏平凡文摘

十年之后再看“面向对象”

993
来自专栏从流域到海域

《笨办法学python》 第14课手记

《笨办法学Python》 第14课手记 本节课将argv和raw_input和起来使用,作者在之前说,这个组合是个蛮顺手的用法。请注意,引入argv并使用arg...

20210
来自专栏Jimoer

Java设计模式学习记录-责任链模式

 已经把五个创建型设计模式和七个结构型设计模式介绍完了,从这篇开始要介绍行为型设计模式了,第一个要介绍的行为型设计模式就是责任链模式(又称职责链模式)。

942
来自专栏编程一生

JVM知识在离线数据中的运用

1313
来自专栏斑斓

Martin Odersky访谈录所思

ThoughtWorks的「TW洞见」在4月发布了对Scala之父Martin Odersky的访谈。Odersky的回答显得言简意赅,仔细分析,仍然能从中收获...

3135
来自专栏C/C++基础

面向对象设计原则(1)——学习使用设计模式

设计模式(Design Pattern)是一套被反复使用、多数人知晓、分类编目、代码设计经验的总结。使用设计模式是为了提高代码的可复用性、可扩充性可维护性,让代...

583

扫码关注云+社区