标签：peter parse 成本 googl 人工智能 价值 最好 this 服务
Python翻译成汉语是蟒蛇的意思，并且Python的logo也是两条缠绕在一起的蟒蛇的样子，然而Python语言和蟒蛇实际上并没有一毛钱关系。
Python语言是由荷兰程序员Guido van Rossum，江湖人称“龟叔”，独立开发完成初版的。“龟叔”曾供职于google，现任职于dropbox 。1989年圣诞节期间，在阿姆斯特丹，为了打发圣诞节的无趣，决心开发一个新的脚本解释语言，作为ABC语言的一种继承，然后他就这么做了，并实现了（大神的能力）。之所以选中Python作为该编程语言的名字，是因为他是一个叫Monty Python喜剧团体的爱好者，其本意并不是想选条蟒蛇。
Python语言的特点
“内置电池”，大量的标准库和第三方库
Python为我们提供了非常完善的基础库，覆盖了系统、网络、文件、GUI、数据库、文本处理等方方面面，这些是随同解释器被默认安装的，各平台通用，你无需安装第三方支持就可以完成大多数工作，这一特点被形象地称作“内置电池（batteries included）”。
在程序员界，有一句话叫做“不要重复造轮子”。什么意思呢？就是说不要做重复的开发工作，如果对某个问题已经有开源的解决方案或者说第三方库，就不要自己去开发，直接用别人的就好。不要过分迷信自己的代码能力，要知道，能作为标准库被Python内置，必然在可靠性和算法效率上达到了目前最高水平，能被广泛使用的第三方库，必然也是经受了大量的应用考验。除非公司要求，不要自己去开发，请使用现成的库。那些造轮子的事情，就交给世界最顶尖的那一波程序员去干吧，没有极致的思维和数学能力，想创造好用的轮子是很难的。
社区活跃，贡献者多，互帮互助
技术社区的存在就相当于程序员手中的指南针，没有指南针，很多时候，碰到了问题，就像无头的苍蝇只能到处乱飞，最终在茫茫的海洋中转晕致死。技术社区可以给我们对语言的学习和使用提供巨大的帮助，无论是前期的学习，还是日后的工作，只要有问题，技术社区的大牛都可以帮我们解决，有这些助力，可以帮我们更好地了解、学习和使用一门语言。技术社区同时还推动Python语言的发展方向，功能需求，促使公司企业更多的使用Python语言，招聘Python程序员。
然而、然而，上面说的是国外。在国内，好像没有比较成熟，影响范围广的Python技术社区，还是说我见识浅薄不知道而已？据本人分析，有历史原因和Python流行过程中形成的习惯等因素，国外Python高手都喜欢用邮件列表、wiki等方式进行交流，而国内喜欢的论坛、bbs等没有形成规模，所以造成现在的状况。
因此，同学们，学好英语，去和世界范围的程序员交流吧！
开源语言，发展动力巨大
Python是基于C语言编写的，并且使用GPL开源协议，你可以免费获取它的源代码，进行学习、研究甚至改进。众人拾柴火焰高，有更多的人参与Python的开发，促使它更好的发展，被更多的应用，形成良性循环。Python为什么会越来越火就是因为它的开放性，自由性，聚起了人气，形成了社区，有很多人在其中做贡献，用的人越来越多，自然就提高了市场占有率，企业、公司、厂家就不得不使用Python，提供的Python程序员岗位就越来越多，这就是开源的力量。
这里附带跟大家说一个代码封闭的问题。Python写的源代码通常是不加密的，如果要发布你的Python程序，实际上就是发布源代码，这一点跟C语言不同，C语言不用发布源代码，只需要把编译后的机器码（也就是你在Windows上常见的xxx.exe文件）发布出去。要从机器码反推出C代码基本是不可能的，所以，凡是编译型的语言，都没有这个问题，而解释型的语言，则必须把源码发布出去。如果你不想让别人看到或抄袭你写的python代码怎么办？使用类似py2exe的包装工具，将python源码转换成一个类似于exe可执行文件的形式，但这个也不是绝对保险，只是增加了反编译的门槛和难度，对于有经验的人而言，一样可以获得你的源代码。
你可能要问，我要通过写代码编软件卖出去挣钱怎么办？少年！目前的互联网时代，靠卖软件授权的商业模式越来越少了，靠网站服务和移动应用卖服务的模式越来越多了，这种模式不需要把源码给别人。再说了，现在如火如荼的开源运动和互联网自由开放的精神是一致的，互联网上有无数非常优秀的像Linux生态圈一样的开源项目，我们千万不要高估自己写的代码真的有非常大的“商业价值”。在Python的世界，开源是王道，不要纠结你的代码被抄袭模仿，而是尽量提高自己的水平和能力，这才是立身之本。
Python的应用方向
Python之禅
最后，让我们以Python的官方格言，也就是俗称的Python之禅来结束对Python的介绍。在Python的IDLE或者交互式解释器中，输入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!翻译过来就是：
优美胜于丑陋（Python 以编写优美的代码为目标）
明了胜于晦涩（优美的代码应当是明了的，命名规范，风格相似）
简洁胜于复杂（优美的代码应当是简洁的，不要有复杂的内部实现）
复杂胜于凌乱（如果复杂不可避免，那代码间也不能有难懂的关系，要保持接口简洁）
扁平胜于嵌套（优美的代码应当是扁平的，不能有太多的嵌套）
间隔胜于紧凑（优美的代码有适当的间隔，不要奢望一行代码解决问题）
可读性很重要（优美的代码是可读的）
即便假借特例的实用性之名，也不可违背这些规则（这些规则至高无上）
不要包容所有错误，除非你确定需要这样做（精准地捕获异常，不写 except:pass 风格的代码）
当存在多种可能，不要尝试去猜测而是尽量找一种，最好是唯一一种明显的解决方案（如果不确定，就用穷举法）
虽然这并不容易，因为你不是 Python 之父（这里的 Dutch 是指 Guido ）
做也许好过不做，但不假思索就动手还不如不做（动手之前要细思量）
如果你无法向人描述你的方案，那肯定不是一个好方案；反之亦然（方案测评标准）
命名空间是一种绝妙的理念，我们应当多加利用（倡导与号召）标签：peter parse 成本 googl 人工智能 价值 最好 this 服务
原文地址：https://www.cnblogs.com/sakura579/p/12243269.html
