2023年政策修订增补工作正在进行中,欢迎参与!
  • Moegirl.ICU:萌娘百科流亡社群 581077156(QQ),欢迎对萌娘百科运营感到失望的编辑者加入
  • Moegirl.ICU:账号认领正在试运行,有意者请参照账号认领流程

Python娘

萌娘百科,万物皆可萌的百科全书!转载请标注来源页面的网页链接,并声明引自萌娘百科。内容不可商用。
跳转到导航 跳转到搜索
Python logo(新).png
萌娘百科欢迎您参与完善本条目☆Kira~
欢迎正在阅读这个条目的您协助编辑本条目。编辑前请阅读Wiki入门条目编辑规范,并查找相关资料。萌娘百科祝您在本站度过愉快的时光。
Commons-emblem-success.svg
本文部分内容经作者団子授权转载至萌娘百科。原文网址:http://python.jobbole.com/63311/
Life is short,you need Python.
人生苦短,我用蟒蛇[1]
——Bruce Eckel
Python.jpg
基本资料
本名 Python
别号 派森、大蟒
身高 153cm
体重 44kg
年龄 30岁
生日 1994年1月26日
血型 A型
星座 水瓶座
萌点 眼镜蓝发短发大小姐连衣裙蛇控
出身地区 荷兰阿姆斯特丹
活动范围 全球
所属团体 Python软件基金会
亲属或相关人
爸爸:Guido van Rossum;
姐妹:C语言娘JavaScript娘Arcaea

Python娘是程序设计语言Python的拟人化萌娘。

简介

眼镜蓝发短发、个性认真(缩进)所有编程语言娘条目唯一依赖缩进来区分代码块范围的,对蟒蛇有种奇妙的兴趣,喜欢简单简洁的东西,有个寻找自我了无音讯的 姐姐

Python娘和其他程序设计语言娘非常玩得来,关系最好的大概是C语言娘了,因为几乎所有事都是C语言娘帮她干的。

虽然外表看起来超严格超认真,但是Python娘其实很好相处推倒哦,平易近人,端庄得体。

据称可用于交♂易

不过听说和妹妹关系不是很好... 语法不兼容

# 在前面加上"#"的语句会被Python娘忽视,除非放在文件头用于声明解释器或编码。

''' ''' Python中多行注释使用三个单引号(''')或者三个双引号(""")来标记,而实际上这是多行字符串的书写方式,并不是Python本身提倡的多行注释方法。

Python由于开发定位上就是解释性语言,因此导致了一些特性:

  • 语法多样,语法糖丰富。
  • 运行速度较慢。废话,逐行解释能不慢吗?
  • 不存在官方打包手段,第三方打包手段效果不佳。[2]

Python娘:不许说人家坏话~

现已披上信息技术娘的马甲,加入高考娘的团队[3]

Python语言程序设计已经光荣的成为计算机二级考试[4]的科目之一了。

人设

由Guido的父亲养大的深闺中的大小姐,前世是ABC语言娘。她出身于荷兰的阿姆斯特丹,但在小时候就搬到了美国,父亲也在家里使用英语。

她个性随和。最出名的是她听C++宣布“想出去旅行一趟改变一下形象。200x年回来哦”出门旅行后(结果回来的时候已经2011年了……),放言说“我也稍稍出门旅行一下,公元3000年再回来哦”后出门数年未归。

虽然有着这样冒失的行动,但多亏抱着“养成大家都喜爱的孩子”的心愿的Guido父上大人的教育,实际上和她接触后会觉得她非常容易亲近。

前些天,她来到作者的朋友的公司打工(她现在似乎在边上大学边打工),被人们评价为“能充分融入工作、八面玲珑、给我们帮了大忙”。她不怎么说多余的话,彬彬有礼的样子,被评价为是在“天真烂漫、自由第一”的人众多的业界中与众不同的存在。

据说她擅长的科目是数学,经常看到她轻松地解决各种统计相关的难题。喜欢穿白色的连衣裙或浅粉色的开衫这样清新的服装。

实际上她还喜欢爬行动物,据说在家里还有养(听说是受父亲爱看电视节目《巨蟒飞行马戏团》的影响)。粉丝们经常讨论“她会给宠物们起什么样的名字呢?”这样的话题。大多得出的都是“肯定是Monty吧”这样的结论。会不会飞就不得而知了。(估计指的是英国的六人喜剧团体Monty Python的作品The Flying Circus)取名为ARC色盲模式!

Python之禅

Tim Peters在Python娘诞生之初,为她写了一首诗。 (在shell中输入import this获得)

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!


反过来再看看实现它的代码

#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):#65是ASCII里大写字母A的代码,97是小写字母a的代码
    for i in range(26):#以此延后的26个字母
        d[chr(i+c)] = chr((i+13) % 26 + c)#配置正确的解密字典

print("".join([d.get(c, c) for c in s]))#使用字典还原s中的字母并存进列表中,再转化为字符串

真的是Beautiful、Explicit、Simple、Complex,十分好的Readability

直译

优美胜于丑陋[注 1]
明了胜于晦涩[注 2]
简洁胜于复杂[注 3]
复杂胜于凌乱[注 4]
扁平胜于嵌套[注 5]
间隔胜于紧凑[注 6]
可读性很重要yyds[注 7]
即便假借特例的实用性之名,也不可违背这些规则[注 8]
不要包容所有错误,除非你确定需要这样做[注 9]
当存在多种可能,不要尝试去猜测
而是尽量找一种,最好是唯一一种明显的解决方案[注 10]
虽然这并不容易,因为你不是 Python 之父[注 11]
做也许好过不做,但不假思索就动手还不如不做[注 12]
如果你无法向人描述你的方案,那肯定不是一个好方案;反之亦然[注 13]
命名空间是一种绝妙的理念,我们应当多加利用[注 14]
[5]

  1. Python以编写优美的代码为目标
  2. 优美的代码应当是明了的,命名规范,风格相似
  3. 优美的代码应当是简洁的,不要有复杂的内部实现
  4. 如果复杂不可避免,那代码间也不能有难懂的关系,要保持接口简洁
  5. 在不增加工作量的情况下,面向过程比面向对象好;如果某函数只被调用一次,那就不如不要建这个函数
  6. 优美的代码有适当的空行,不要一大坨代码解决问题与语文作文守则“不要一逗到底”有异曲同工之妙
  7. 优美的代码应该具有易懂的命名,适当而不过多的空行,以及丰富的注释而写注释正是程序员最讨厌的事情之一
  8. 这些规则至高无上
  9. 精准地选择某类异常进行处理,不要except Exception: ...(除非你不知道可能会发生什么异常,需要知道异常信息)
  10. 如果不确定,就用穷举法
  11. 这里的 Dutch 是指 Guido
  12. 动手之前要细思量
  13. 方案测评标准
  14. Python中import...使用对应的库函数依然需要库名.函数名,类似C++中标准库命名空间的使用方法std::,而from...import *又类似于using namespace std;取消了库名/命名空间。可能是C的两个妹妹长得比较像吧?
六言

优雅胜于丑陋,直白胜于委婉
简单胜于复杂,复杂胜于混乱
单层胜于嵌套,稀疏胜于稠密
以上六条之外,可读也很重要
即使情况特殊,规则不应打破
实用胜于纯净,尽管优雅更好
错误不应忽视,除非显式沉默
面对模棱两可,拒绝猜的诱惑
明显解决办法,应当只有唯一
方案不尽明显,除非来自荷兰
肝爆胜于摸鱼,不咕胜于咕咕
但是立即完成,通常不如咕咕
请君向人解释,实现问题方法
难以解释为劣,通俗易懂为好
命名空间极妙,咱们一起来搞

使用Python编辑

萌娘百科所使用的MediaWiki并不支持直接解析Python代码,不过可以通过Python创建维护wiki的机器人(bot),从而实现大量编辑或者删除等维护操作。

具体使用Python编辑的方法可参考:Help:使用Python编辑


外部链接与注释

Wikipedia-logo-v2.svg
维基百科
提示您
  1. 英文单词“python”的原意为“蟒蛇”。
  2. 在不使用参数的情况下大多数打包器都会把所有库文件全部打包进去,导致程序打包后是原来的几十~几千倍。
  3. 2019版浙教版信息技术教材使用Python作为编程语言,使用Python编程的试题已于2023年1月浙江技术选考中首次出现。
  4. 全国计算机等级考试(National Computer Rank Examination,简称NCRE),是经原国家教育委员会(现教育部)批准,由教育部教育考试院(原教育部考试中心)主办,面向社会,用于考查应试人员计算机应用知识与技能的全国性计算机水平考试体系。
  5. 其实这些注释什么具体的东西都没讲出来……听君一席话,如听一席话