Python开发者沙龙之后的小感想
2016-03-19 参加了Python开发者沙龙,记录下
昨天大老远跑到杨浦区去参加Python开发者沙龙,主要是听听牛人对Python的认识和见解,也想和喜欢python的朋友们进行线下的交流,同时也想知道自己大概是处在什么样的水平上。
结果一早我就背着我那有厚有重的T430和一堆线和移动电源出发了,大概坐地铁要一个小时才能到杨浦,我就带着我现在的宝贝《Effective C++》在车上看(最后事实证明其实我只需要带着本书就够了,电脑啥的压根我就没打开。
早到了一个小时,我还是喝了杯咖啡接着看我的宝贝。
。。。好烦,不想再记流水账了,直接进入主题吧
一般人不知道的python秘密
这个是Coding CTO 孙宇聪讲的报告,主要讲解了他在Google使用python的一些原因和经历,对python中的一些优缺点进行了评价,同时对python内置的基本数据类型进行了简单的讲解其中最重要的还是python中避不开的话题GIL(全局解释器锁)。
虽然都是很基础的东西,但是在大牛的解说下我对以前虽然知道的东西的认识也加深了。
这里我就不再讲python的优点了,任何一个使用python的人肯定初见python时都会深深体会到他的优点并为之痴迷。但是世界上并没有完美的东西,优点的背后就是掩藏着的缺点与不足。
动态类型
这个问题是在python,js上面很常见的问题,变量定义时并不声明其类型,这就会造成使用python进行运算时需要解释器去动态的判断其类型,必然会造成效率上的问题和项目庞大以后的一些未知的隐患。python的对象模型
python中一切皆对象,就连int什么的也是一个PyObject
, 这就会造成占用内存和运行效率低下的问题。python的强制缩进(没有大括号)带来的不方便之处
有的时候一个code block
写的很长超过一个屏幕时候,这种特点就会造成对应代码段困难。这时候大括号就会让人开始想念了。同样的,之前知乎上的@vczh也说过看python教程的时候最怕的应该就是翻页了吧,一旦翻页,没有中括号就会让人头疼。python中的string
在python3.0之前,对Unicode的支持真的是和翔一样,不谈了。python的List
python中List并不是数据结构中的链表结构,他其实是一个动态的数组。如下图:
可以看到,List对象中的数据成员包含list长度和items,其中items中存储着List中数据的指针,然后通过指针去操作真正的数据(这里由于我没看过python源码剖析,只能大概的理解下了。
这里就会遇到一个问题,就是由于List不是链表而是数组,那么对于插入数据和删除数据的复杂度将不是 $O(1)$ ,而是 $O(n)$ ! 所以要尽量减少对List的插入和删除操作。当然我平时是几乎很少用到insert
这种的。python中的Tuple
Tuple是不可变的,因此在做函数参数的时候以及返回值的时候都是返回的tuple,谁也不想传入和返回的值是个可变的list吧,这样带来的将会是未知的隐患。
全局解释器锁(GIL)
这个真是已经是使用python的人没有一个不知道的东西了,经常会被人喷,说python没有真正的多线程。不过的确,GIL的存在使得python解释器中同时只能跑一个线程。使用multi-threading面对计算密集型的程序通常会使得效率降低!这样串行反而对于python是高效的做法。
所以面对计算密集型程序使用多进程利用多CPU的优势来实现并行,感觉像是开了多个解释器,使用Pool
和process
也是很简单形象的。
我的小感想
当然在最近这两年强度比较大的使用python的情况下我也感受到了python的一些缺点,最近在写C++深深体会到python为了易开发而付出的效率上的代价,很多的语法糖,导致程序效率降低。慢慢的我对python的认识也渐渐趋于了理性,后续又使用C和C++使用SWIG来给python写extension,这样不仅能在语言层面上提升python的效率,也能够使用OpenMP和MPI等方式实现并行化。
的确,python的角色在不同领域甚至是不同大小的公司内部扮演的角色是不一样的。
- 在Google这种大公司的确是希望写的程序能够运行十年是目标,因此稳定性是主要的,而不是开发速度,因此在这种角度来看python也许并不是合适的语言。但是对于小公司而言python开发快的特点是必需的。当然作为万金油,在服务器写脚本和做运维python可算是如鱼得水了。
- 对于科学计算,我觉得我还是很有发言权的。这个真的是要看科学计算的需求了,如果仅仅是进行算法的验证和尝试,用python写个小demo测试是效率很高的。没人喜欢用C或者C++写好函数写好驱动程序然后在编译这么麻烦吧。但是真的想用写好的程序开始大规模做计算获取数据的时候,一份高效规范的代码往往节省的时间是很可观的,谁也不想程序崩溃了都不知道是什么原因,然后找到写程序的人把程序改好然后在到每个计算节点编译安装一遍吧。所以这个时候选择C/C++来将其重写,外层在使用python将其封装调用,将内外层分离开来,外层可以用写的快的python写一些plugin但是内层C/C++编译好了可以不用再动了。
不过我是能够感受到python社区是个健康蓬勃发展的,我很看好python的未来。