Python简介
Python是当前非常热门、应用范围非常广、使用人员非常多的编程语言。每年都有很多的初学者开始接触并爱上Python语言。作为一门开源的编程语言，其学习教程、技术书籍有很多，各有优缺点。
Python是一门强大的语言，可用于Web开发、自动化运维、科学计算、 络爬虫、数据分析、机器学习、深度学习等几乎所有主流应用方向。尤其是Python+Django的Web开发组合。更是开发大型新闻 站、博客系统、自动化运维凭他的最佳选择。
Python：翻译成汉语是蟒蛇的意思，并且Python的logo也是两条缠绕在一起的蟒蛇的样子，然而Python语言和蟒蛇实际上并没有关系。
Python的口 是：”人生苦短，我用Python！”。这条口 被Python业界广泛使用，快成了广告词一类的存在。
Python语言是荷兰程序员Guido van Rossum，江湖人称”龟叔”，独立开发完成初级的。”龟叔”曾就职于google，现就职于dropbox。1989年圣诞节期间，在阿姆斯特丹为了打发圣诞节的无趣，决心开发一个新的脚本解释型语言，作为ABC语言的一种继承，然后他就这么做了，并实现了(大神的能力)。之所以选中Python作为该编程语言的名字，是因为他是一个Monty Python
喜剧团体的爱好者，然而并不是想想选择蟒蛇。
Python第一个公开发行版发行与1991年，所以这年当做Python的诞生年。
Python源码遵循GPL（GNU General Public License）协议，这是一个开源协议，也就是说你可以免费使用和传播，而不用担心版权为题。
目前Python是由一个核心团队维护，龟叔属于太上皇职位，仍然占据着至关重要的作用，指导其进展。
一、Python的发展趋势
五、Python的缺点
我们光说了Python的优点，也得说说它的缺点。任何编程语言都有缺点，Python也不例外。
第一个缺点就是运行速度相对慢点，和C程序相比慢不少，这是解释型语言的通病，你的Python代码在执行时会一行一行地翻译成CPU能理解的机器码，这个翻译过程非常耗时，所以会变慢。而C程序作为编译型语言是运行前直接编译成CPU能执行的机器码，所以非常快。（但同时你可以这么理解，C语言把费时间的活在生产上线之前先花时间干了，所以运行时就快了。）
但是Python的慢，没有你想象中的那么严重那么重要，因为：
程序速度不再那么重要，不一定非要追求极致
前面其实我们已经提到过，早些时期CPU比较昂贵，计算资源很吃紧，内存也很贵，程序运行的速度和耗费的时间就很重要。这就是导致计算机科学致力于研究不同算法的效率的原因之一。然而，这已经不再是最重要的因素，因为现在芯片很便宜，而且运行速度有了质的提升。运行时间不再是你最贵的资源。公司最贵的资源现在是员工时间。或者换句话说，就是你。在规定时间内把事情做完比把程序变快更加重要。Python语法简洁，包含大量的标准库和第三方库，用较少的语句就可以完成其它语言上百条语句才能完成的任务，这无疑大大提高了开发的速度和效率，帮助你在尽可能短的时间内完成工作。
这里并不是说速度一点也不重要，只是说速度不再是唯一重要的东西和唯一考虑的东西。 现在，产品的研发速度远比程序运行速度更重要。在一天结束时，让你的公司存活下来或者死去的唯一事物就是产品上市时间。公司能够存活下来的唯一方法就是比你的竞争对手更快地创新。如果在你的产品上市之前，你的竞争对手已经提前上市了，那么你想出了多少好的主意也将不再重要。
在整个体系中有比Python程序运行得更慢的瓶颈：
如果你在写一个 络应用程序，如web服务，很有可能的情况是，CPU时间并不是你的程序的瓶颈。当你的web服务器处理一个请求时，可能会进行几次 络调用，例如到数据库，或者像Redis这样的缓存服务器。虽然这些服务本身可能比较快速，但是对它们的 络调用却很慢。如果一个单独的CPU周期等同于1秒，那么一个从北京到上海的 络调用将相当于1年。可见 络调用是多么的慢。这说明什么呢Python不是系统中最慢的那个部分，有比它慢数量级的运行瓶颈卡在系统中间，制约着整个系统的运行速度。
但无论怎么样，Python慢是事实。如果你真的对提高Python运行速度有需求，你可以使用C来写，然后在Python中调用它
另外，程序员大牛Donald Knuth说过过早优化是万恶之源。在开发的中早期，追求运行速度和效率是费力不讨好的，进行敏捷开发和快速迭代才是当下软件开发的王道模式，而Python正是为此而生。
第二个问题就是GIL（Global Interpreter Lock）全局解释器锁，这是一种防止多线程并发执行机器码的互斥锁，功能和性能之间权衡后的产物。这是在设计Python语言的时候留下的一个历史性遗留问题，也是限于当时技术团队实力有限。具体的技术细节先不解释，其造成的后果就是Python在进行多线程任务的时候，其实是伪多线程，性能较差，这一点一直被诟病，大家随便在某个技术论坛里都能找到对这个问题的激烈讨论。Python的这个问题事实存在，一段时间内也是无法解决的，为什么呢要从底层重新设计Python，难度之大，工作量之大，对现有生态圈的影响非常巨大。那么有什么解决办法非官方的PyPy解释器或者协程机制。
第三个不是缺点的问题是Python2和Python3的不兼容性
六、 Python之禅
>>> importthis
The Zen of Python, by Tim Peters
Beautifulisbetter than ugly.
Explicitisbetter than implicit.
Simpleisbetter than complex.
Complexisbetter than complicated.
Flatisbetter than nested.
Sparseisbetter than dense.
Readability counts.
Special cases aren’t special enough to break the rules.
Although practicality beats purity.
Errors should neverpasssilently.
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 maynot be obvious at first unless you’re Dutch.
Now isbetter than never.
Although neveris often better than *right*now.
If the implementationis hard to explain, it’s a bad idea.
If the implementation iseasy 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 ）
做也许好过不做，但不假思索就动手还不如不做（动手之前要细思量）
如果你无法向人描述你的方案，那肯定不是一个好方案；反之亦然（方案测评标准）
命名空间是一种绝妙的理念，我们应当多加利用（倡导与 召）
文章知识点与官方知识档案匹配，可进一步学习相关知识Python入门技能树预备知识Python简介215105 人正在系统学习中 相关资源：移动叔叔线刷软件-Android工具类资源-CSDN文库
声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！