|
Size: 7369
Comment:
|
Size: 17536
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 19: | Line 19: |
| 在昨天内部分享交流中,俺回顾了 PyCon2011China 中透露出的 Py 最新使用/发展和体验; | 在昨天内部分享交流中,俺回顾了 `PyCon2011China` 中透露出的 Py 最新使用/发展和体验; |
| Line 108: | Line 108: |
| * ~ HYRY ^发送时间 07:16 (GMT-08:00)。发送地当前时间：下午5:08。 ✆^ * 有时候写 `__eq__,__ne__`方法不是为了比较，而是为了生成别的代码，例如SQL。我最近正好写了一个编译器，它需要在某些条件下在 `__eq__,__ne__`中抛出不同的异常。如果没有`__ne__`那就麻烦了。 |
|
| Line 109: | Line 111: |
| Line 115: | Line 116: |
| {{{ Leo Jay python.leojay # gmail.com 发件人当地时间: 发送时间 17:19 (GMT+08:00)。发送地当前时间：上午9:10。 ✆ }}} 说到这个我想起来，python的文档很SB的地方是，它很少说一个方法调用是否会抛异常以及抛什么类型的异常。 * 比方说int这个函数，它就说了句：如果转入参数不是字符串，会抛TypeError，然后就没了。要是你因此你只抓TypeError的话就傻了，因为如果字符串不是数字的话，抛的是ValueError。 * 如果因此，你写try ... except代码都写成 {{{#!python try: foo() except: ... }}} * 的话，你也可能中招，因为sys.exit()的退出方式就是抛一个异常。如果你foo()有逻辑在一定情况下调用sys.exit来退出的话，你会发现这个异常被你抓掉了。。。 所以我现在养成习惯，代码都写成： {{{#!python try: foo() except Exception: ... }}} 而更多的方法，比如time.sleep，文档压根就不告诉你，它可能会抛异常。 === 依云 :中文问题! === {{{ lilydjwg # gmail.com 发件人当地时间: 发送时间 17:20 (GMT+08:00)。发送地当前时间：上午9:11。 ✆ }}} On Wed, Dec 21, 2011 at 04:05:19PM +0800, 智障 wrote: > 俺觉得俺现在用着Python2也挺好，编码问题不是什么大问题加#-*- coding:utf-8 -*-用章鱼编辑器的自动插入功能，也挺方便。 如果你认为所谓的「编码问题」指的是这个的话你就大错特错了。Python 2 在引 入 Unicode 后即混淆了 str 和 unicode——在一个需要字符串的 API，你既可以传 str 也可以传 unicode。有些 API 没处理好，如： {{{ >>> os.path.join('中文', u'路径') Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/usr/lib/python2.7/posixpath.py", line 71, in join path += '/' + b UnicodeDecodeError: 'ascii' codec can't decode byte 0xe4 in position 0: ordinal not in range(128) }}} 经常会遇到这种情况。然后你 encode 或者 decode 一下就解决了。问题是，这种 问题没有规律。 还有一个问题是， {{{ >>> '中文' '\xe4\xb8\xad\xe6\x96\x87' >>> u'中文' u'\u4e2d\u6587' }}} repr 的结果不可读。这意味你 print 一个 list 或者 dict 什么的，你看不到其 中的中文。 ==== pansz 指正 ==== {{{ pan.shizhu # gmail.com 发件人当地时间: 发送时间 08:24 (GMT+08:00)。发送地当前时间：上午9:13。 ✆ }}} * 其实不存在混淆 str 跟 unicode 的问题，需要 str 的地方会自动把 unicode 转成 str，需要 unicode 的地方会自动把 str 转成 unicode。 * 问题在于缺省的转换使用的 ascii 编码，因此只要含有中文的，一律不能通过 python2 的"自动类型转换"。 * 所以编程过程中凡是存在这种"自动类型转换"的环节，一律需要改成手动转换。----我以为只要理解这个，几乎可以解决python2 90%以上的编码问题。 * `repr 的结果不可读` ... 这个问题产生的原因跟上述是一样的，py2 缺省输出ascii ，不是 utf-8 。。。因而自然不能看到。 * 但是如果你只是要 print 的话，一个非常非常简单的办法是：`输出为 json，并指定为 utf-8 格式`，json编码器增加 default 函数为 repr(obj)。这样的输出几乎跟 repr 完全一致，除了那些乱码中文变成了真正的 utf-8 中文。 其实说了那么多， py3 对国人唯一的重要改进仅仅是"缺省编码由 ascii 修改为了utf-8"而已。 * 为了这点点改变去伤筋动骨的大修整个语言，并且弄得向后不兼容。有点太过了。简单的修改一下 python2 源代码就能做到的事。。。 |
|
| Line 135: | Line 212: |
| `总之，越来越多的“懂OO的java工程师“进入python领域，导致python越来越差劲` === shhgs === {{{ shhgs.efhilt # gmail.com 发件人当地时间: 发送时间 18:56 (GMT-05:00)。发送地当前时间：下午8:06。 ✆ }}} 问题还是很多的 * 1. 匿名函数。Py3一度要取消lambda，脑残了不是。正确的做法应该是进一步加强lambda，搞匿名函数 * 2. 莫名其妙的local域。我写twisted的时候，没少吃药。稍微不留神就掉坑里。 * 3. 很多类库的port都不完整。socket，readline，ncurse 。。。 * 4. 为什么要区分表达式和语句？有这个必要吗？表达式全部返回None，或者专门定义一个Void岂不是更好？ * 5. Py的标准类库应该修订一下了。标准类库的质量良莠不齐，有些类库明显落伍。htmllib, * sgmllib ，HTMLParser，现在还有人用吗，为什么不用lxml？re，建议用pcre；ConfigParser，建议去掉。 * 6. 进一步增强easy_intall。应该设计类似rpm, dpkg这样的Python library package。以类似yum，apt的方式分发这种包。 === Shell Xu === {{{ shell909090 # gmail.com 发件人当地时间: 发送时间 22:06 (GMT+08:00)。发送地当前时间：上午9:01。 ✆ }}} python的整个系统，我其实有非常多的不满。但是用任何一门语言都是取舍问题，如果有一门语言，库够多，已读，易用，性能高，我毫不犹豫立刻转过去。python的强处在于庞大的库，还有非常好的易读和易用性。 * 但是相比来说，性能一直是个问题。python的实现性能大约和C相差五倍上下。如果是大规模计算问题，大约能差10倍以上。当然，我们可以写C扩展，但是这就不是使用python了。我们也可以说，很多时候我们不需要这么快的速度。这是个事实，但是不改变python性能差的事实。python不但性能差，还有GIL这个玩意。以至于我现在对高并发计算都采取多进程的模式。多进程模式的通讯效率肯定比多进程低，而且麻烦。 * 另外，python在底层设计上，也表现出很强的实用主义倾向。这是比较外交术语的词汇，更加直白的说法应当是，混乱，不知所谓。在闭包设计上采用free variable设计，而不是lisp中的environs设计。区别？ * 你试试看在外层闭包中 `from lib import *`。由于引入不定个数名称，free variable无法处理。类似的问题还有LEGB规则，新手往往要花很长时间研究这个例子究竟是怎么错的： {{{ #!python a = 1 def f(): print a a = 2 }}} * 我勒个去，这种反直观反人类的事情都有，还敢说自己易读。 * 还有坑爹的元编程，这东西根本是坑爹中的坑爹货。如果你用过多重继承，大概就知道python的整个OO系统看起来根本是大型的仿真，到处都是乱糟糟的。C++怎么解决多重继承的？你最好别用（真心说，这可比python更加坑爹）。java怎么解决多重继承的，只能继承Interface。其实这是变相的变成了Interface-Impalement模式。python怎么解决的？MRO！为什麽一个类加个__metaclass__就会改变性质啊，为什麽一个类去生成另一个类的写法是----我基本不记得了，反正web.py里面有用到，需要的话去炒栗子吧。为什麽方法要隐藏居然要改名字加__啊。你到底是在做OO还是在看起来像OO的东西上狂打补丁啊魂淡。 * lambda表达式弱智。我和人讨论过，lambda是否是图灵完备的。结论还是完备的，不过需要借助Y combinator。何必呢？由于强调lambda的快速特性，因此将lambda强制在一行以内（没有结束标记），导致python其实是没有匿名函数的。一个callback数组写的难过死。 * 语法糖太多了点，当然，这是纯粹的个人感觉。语法糖是把双刃剑，用的好，可以简化编写和阅读，但是太多，往往容易引入语法混乱和额外的约束。 * 另外，语言的自构建特性混乱。虽说不是每门语言都强调自构建特性，但是通常而言，都是使用C实现一个内核，由内核实现一些基础操作。再由基础操作实现更复杂的操作。每层的边界都是比较清晰的。谁来告诉我，python中有多少库在移植时是由纯python实现的？库的相互依赖层级是？ * python的沙盒化也是个问题，如果沙盒做的够好，我完全可以把python作为一个客户级别的平台。用C写一个很简单的类似浏览器的东西，下载一个URL的python包回去运行（或者仅仅检查更新）。从而保证本地效果/跨平台/安全性。现在？一个都保证不了。我连把一个python包转移到另一台同构设备上都很麻烦（如果两者不是严格匹配，例如系统差异，系统版本差异）无论是web开发还是移动终端开发都必须走传统模式。 === 赖勇浩 === {{{ mail # laiyonghao.com 通过“googlegroups.com” 发件人当地时间: 发送时间 22:31 (GMT+08:00)。发送地当前时间：上午9:04。 ✆ }}} 个人看法：支持 native thread 是它最大的错误。 === pansz === {{{ pan.shizhu # gmail.com 发件人当地时间: 发送时间 08:35 (GMT+08:00)。发送地当前时间：上午9:15。 ✆ }}} 我觉得这些是缺点： * 1。python3 的存在，python2 如果没缺点 python3 就不需要存在了，源代码还不兼容。这会造成不小的混乱。 * 2。没有一个堪比 Java 性能的 JIT 实时编译解释器。 * 3。源代码无法真正意义上的加密（当然解释执行类语言都有这个问题，Java 也一样，反编译太容易。。。而象 C++ 编译之后基本不可能反出源代码。） Python 目前为止主要用于服务器端，正因为解释型语言都不可能真正意义上的加密源代码，所以只有部署在服务器端能避免这个问题。 |
Contents
Py的缺点?!
提问
Zoom.Quiet zoom.quiet# gmail.com 发件人当地时间: 发送时间 14:24 (GMT+08:00)。发送地当前时间：下午5:03。 ✆ 主题: [PyCon2011China]后续思考: Py 有什么缺点?!
在昨天内部分享交流中,俺回顾了 PyCon2011China 中透露出的 Py 最新使用/发展和体验; 最后有同学问:
- Python 有什么缺点!?
直接HOLD 住了俺的思路...
- 是也乎!?
- 世界上没有完美的语言
- Python 相比各种开发语言也有缺点,当然的!
可是,是什么呢?!
- 没有 {} ?
- 不支持多CPU ?大家在学习使用过程中,对 Python 有什么失望的地方?! - 兼听则明 - 现在不满意的,就是我们努力的方向..
PS: - 俺现场憋出的回答是:
- - 由于 Py 历史上积累的好用模块太多，会导致开发人员更加懒惰，不思进取，不论什么都可以直接搜出可用的现成模块来!
zw g
zw g pekingmaster# gmail.com 发件人当地时间: 发送时间 14:55 (GMT+08:00)。发送地当前时间：下午5:04。 ✆
- 1）iOS, Android等移动设备的App开发目前感觉不给力 (不是指web的方式)
- 2）性能
- 3）多核？
- 4）GIL？
- 5）编译打包流程
Leo Jay
Leo Jay python.leojay# gmail.com 发件人当地时间: 发送时间 14:58 (GMT+08:00)。发送地当前时间：下午5:05。 ✆
我不同意说python没缺点。但我也不认为python3是一次大修。 在我看来python3最重要变化，一是print之类的语句变成了函数调用，二是默认使用unicode做字符串。 这能算是大修么？至少我个人认为是不算的。
从我的角度来说，python可以提高的地方，
- 一是运行速度，目前还远不能跟编译型语言比，
- 二是IDE，还没哪款python的IDE能达到intellij idea和eclipse对java的支持
- 三是多线程并发执行的支持
至于语言本身，我没感觉到有什么明显的缺点。
对于那些写代码用英文，写注释用英文，平时也不用处理非英文数据的人来说，转3的动力的确不强。
我的看法是，
- 1. 如果你手上已经有2的项目要维护，那就继续用2，不要做迁移。
- 2. 如果你要新做一个web项目，先去看看cherrypy能不能满足你的要求。如果可以的话，就用3，不行就用2
- 3. 如果你已经知道你要做什么，先去找找相关的库对3是否支持，如果不行，就用2
- 4. 其它情况，能用3就用3
总的来说就是能用3就用3，毕竟3是未来的方向，而且的确有相当一些细节上的改进 但如果不能用3的情况下，那就用2，不要勉强。
ubunoon
ubunoon netubu# gmail.com 发件人当地时间: 发送时间 15:43 (GMT+08:00)。发送地当前时间：下午5:07。 ✆
- 1、大部分使用的是CPython，运行速度与其他编译型语言相比，还是不够快速
- 2、万恶的GIL
- 3、嵌入到C比较麻烦。
- 4、框架太多
- 5、资料还是相对较少
- 6、IDE，很难找出一款好的IDE，来一统Python的天下（或者是桌面或者是web开发）
- 7、商业应用支持还是比较少 （这个才是重点）
8、google复杂问题的解决（就好像之前我发的PySide的问题），还是不够给力。
CJ
CJ jamchange# gmail.com 发件人当地时间: 发送时间 16:57 (GMT-08:00)。发送地当前时间：上午1:08。 ✆
Python的Object & Class 系统有逻辑上的问题
1. Object支持了eq方法，为什么还要实现ne方法？很基本的哲学道理，一个可推导的世界中，A==B为真，则A!=B一定为 假，ne方法大家都不会用，那就应该人Python中去掉，免得引起混乱
~ HYRY 发送时间 07:16 (GMT-08:00)。发送地当前时间：下午5:08。 ✆
有时候写 __eq__,__ne__方法不是为了比较，而是为了生成别的代码，例如SQL。我最近正好写了一个编译器，它需要在某些条件下在 __eq__,__ne__中抛出不同的异常。如果没有__ne__那就麻烦了。
- 2. classobj与type这两个东西确实该去掉一个，鸡乎？蛋乎？（Python 3去掉了classobj）
- Python的字符串unicode，寄期望于Python 3
- Python的lambda只支持表达式，Python仍然区分表达式与语句，这点导致lambda里没了if（虽然你也可以找很多其它的理由来解释 lambda里的代码不应写得复杂），还有Python的closure
- Python函数的tail_call_optimize
- "".join 你懂的，Python有些库的方法命名有些奇怪，有些有下划线，有些没有下划线。有些类是全小写，有些类是Camel，Java这些方 面就很好。。。。历史遗留问题啊
- Python的文档？？？？我看django文档时，只想着一句话：Read The Fucking Source Code！！！有些函数的文档我看半天还是没搞清楚倒底怎么个用法，一是函数参数没有类型说明，另一方面，我还是比较喜欢直接的example。（感觉Java的API文档也要比 Python的好很多喔，整洁不少）。
Leo Jay python.leojay # gmail.com 发件人当地时间: 发送时间 17:19 (GMT+08:00)。发送地当前时间：上午9:10。 ✆
说到这个我想起来，python的文档很SB的地方是，它很少说一个方法调用是否会抛异常以及抛什么类型的异常。
比方说int这个函数，它就说了句：如果转入参数不是字符串，会抛TypeError，然后就没了。要是你因此你只抓TypeError的话就傻了，因为如果字符串不是数字的话，抛的是ValueError。
- 如果因此，你写try ... except代码都写成
- 的话，你也可能中招，因为sys.exit()的退出方式就是抛一个异常。如果你foo()有逻辑在一定情况下调用sys.exit来退出的话，你会发现这个异常被你抓掉了。。。
所以我现在养成习惯，代码都写成：
而更多的方法，比如time.sleep，文档压根就不告诉你，它可能会抛异常。
依云 :中文问题!
lilydjwg # gmail.com 发件人当地时间: 发送时间 17:20 (GMT+08:00)。发送地当前时间：上午9:11。 ✆
On Wed, Dec 21, 2011 at 04:05:19PM +0800, 智障 wrote:
> 俺觉得俺现在用着Python2也挺好，编码问题不是什么大问题加#-*- coding:utf-8 -*-用章鱼编辑器的自动插入功能，也挺方便。
如果你认为所谓的「编码问题」指的是这个的话你就大错特错了。Python 2 在引 入 Unicode 后即混淆了 str 和 unicode——在一个需要字符串的 API，你既可以传 str 也可以传 unicode。有些 API 没处理好，如：
>>> os.path.join('中文', u'路径')
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/lib/python2.7/posixpath.py", line 71, in join
path += '/' + b
UnicodeDecodeError: 'ascii' codec can't decode byte 0xe4 in position 0: ordinal not in range(128)经常会遇到这种情况。然后你 encode 或者 decode 一下就解决了。问题是，这种 问题没有规律。
还有一个问题是，
>>> '中文' '\xe4\xb8\xad\xe6\x96\x87' >>> u'中文' u'\u4e2d\u6587'
repr 的结果不可读。这意味你 print 一个 list 或者 dict 什么的，你看不到其 中的中文。
pansz 指正
pan.shizhu # gmail.com 发件人当地时间: 发送时间 08:24 (GMT+08:00)。发送地当前时间：上午9:13。 ✆
- 其实不存在混淆 str 跟 unicode 的问题，需要 str 的地方会自动把 unicode 转成 str，需要 unicode
的地方会自动把 str 转成 unicode。
- 问题在于缺省的转换使用的 ascii 编码，因此只要含有中文的，一律不能通过 python2 的"自动类型转换"。
所以编程过程中凡是存在这种"自动类型转换"的环节，一律需要改成手动转换。
我以为只要理解这个，几乎可以解决python2 90%以上的编码问题。
repr 的结果不可读 ... 这个问题产生的原因跟上述是一样的，py2 缺省输出ascii ，不是 utf-8 。。。因而自然不能看到。
但是如果你只是要 print 的话，一个非常非常简单的办法是：输出为 json，并指定为 utf-8 格式，json编码器增加 default 函数为 repr(obj)。这样的输出几乎跟 repr 完全一致，除了那些乱码中文变成了真正的 utf-8 中文。
其实说了那么多， py3 对国人唯一的重要改进仅仅是"缺省编码由 ascii 修改为了utf-8"而已。
- 为了这点点改变去伤筋动骨的大修整个语言，并且弄得向后不兼容。有点太过了。简单的修改一下 python2 源代码就能做到的事。。。
zhao shichen
shichen.zhao# gmail.com 发件人当地时间: 发送时间 18:10 (GMT+08:00)。发送地当前时间：下午6:54。 ✆
- 1.很多标准库很烂；而很多很好的库竟然不在标准库之中，比如chardet等等，而xml之类没用的东西反而有
2.lambda演算太弱：如果有类似(x,y)->这样的语法就更好了；python3竟然进一步的削弱了lambda演算的能力
- 3.字符串的join看起来太奇怪了
- 4.发展了自己的一套正则表达式，直接用pcre不好吗。而且这个库的使用我感觉不友好。
- 5.听说python的unix域socket的性能不佳，仅仅是听说，在我的简单测试中感觉unix域socket的速度和普通socket速度一样：应该快一倍才对。
- 6.没有标准的IPC函数,比如共享内存，消息队列等，这些东西很有用阿
- 7.引入了太多java里面的垃圾概念，就是那些面向对象的东西。导致本来很简单的东西搞得很复杂，最典型的例子是logging模块，这个模块太烂了
- 8.socke的函数支持不全,比如sendfile等等都没有支持
- 9.很不喜欢元类编程，把本来很简单的东西搞复杂，都是java里面的垃圾概念
在我的项目组中，基本上不准编写类，只允许编写函数，目的就是为了方便集成和控制代码；
象很多java项目比如eclipse一样搞得又大又臭是绝对没法接受的
总之，越来越多的“懂OO的java工程师“进入python领域，导致python越来越差劲
shhgs
shhgs.efhilt # gmail.com 发件人当地时间: 发送时间 18:56 (GMT-05:00)。发送地当前时间：下午8:06。 ✆
问题还是很多的
- 1. 匿名函数。Py3一度要取消lambda，脑残了不是。正确的做法应该是进一步加强lambda，搞匿名函数
- 2. 莫名其妙的local域。我写twisted的时候，没少吃药。稍微不留神就掉坑里。
- 3. 很多类库的port都不完整。socket，readline，ncurse 。。。
- 4. 为什么要区分表达式和语句？有这个必要吗？表达式全部返回None，或者专门定义一个Void岂不是更好？
- 5. Py的标准类库应该修订一下了。标准类库的质量良莠不齐，有些类库明显落伍。htmllib,
sgmllib ，HTMLParser，现在还有人用吗，为什么不用lxml？re，建议用pcre；ConfigParser，建议去掉。
- 6. 进一步增强easy_intall。应该设计类似rpm, dpkg这样的Python library package。以类似yum，apt的方式分发这种包。
Shell Xu
shell909090 # gmail.com 发件人当地时间: 发送时间 22:06 (GMT+08:00)。发送地当前时间：上午9:01。 ✆
python的整个系统，我其实有非常多的不满。但是用任何一门语言都是取舍问题，如果有一门语言，库够多，已读，易用，性能高，我毫不犹豫立刻转过去。python的强处在于庞大的库，还有非常好的易读和易用性。
- 但是相比来说，性能一直是个问题。python的实现性能大约和C相差五倍上下。如果是大规模计算问题，大约能差10倍以上。当然，我们可以写C扩展，但是这就不是使用python了。我们也可以说，很多时候我们不需要这么快的速度。这是个事实，但是不改变python性能差的事实。python不但性能差，还有GIL这个玩意。以至于我现在对高并发计算都采取多进程的模式。多进程模式的通讯效率肯定比多进程低，而且麻烦。
- 另外，python在底层设计上，也表现出很强的实用主义倾向。这是比较外交术语的词汇，更加直白的说法应当是，混乱，不知所谓。在闭包设计上采用free variable设计，而不是lisp中的environs设计。区别？
你试试看在外层闭包中 from lib import *。由于引入不定个数名称，free variable无法处理。类似的问题还有LEGB规则，新手往往要花很长时间研究这个例子究竟是怎么错的：
- 我勒个去，这种反直观反人类的事情都有，还敢说自己易读。
还有坑爹的元编程，这东西根本是坑爹中的坑爹货。如果你用过多重继承，大概就知道python的整个OO系统看起来根本是大型的仿真，到处都是乱糟糟的。C++怎么解决多重继承的？你最好别用（真心说，这可比python更加坑爹）。java怎么解决多重继承的，只能继承Interface。其实这是变相的变成了Interface-Impalement模式。python怎么解决的？MRO！为什麽一个类加个metaclass就会改变性质啊，为什麽一个类去生成另一个类的写法是
我基本不记得了，反正web.py里面有用到，需要的话去炒栗子吧。为什麽方法要隐藏居然要改名字加啊。你到底是在做OO还是在看起来像OO的东西上狂打补丁啊魂淡。 combinator。何必呢？由于强调lambda的快速特性，因此将lambda强制在一行以内（没有结束标记），导致python其实是没有匿名函数的。一个callback数组写的难过死。
个人看法：支持 native thread 是它最大的错误。
我觉得这些是缺点： Python 目前为止主要用于服务器端，正因为解释型语言都不可能真正意义上的加密源代码，所以只有部署在服务器端能避免这个问题。
发件人当地时间: 发送时间 15:12 (GMT+08:00)。发送地当前时间：下午5:05。 ✆ 回复: [email protected] 反馈 创建 by -- ZoomQuiet [2011-12-21 09:09:06] 赖勇浩
mail # laiyonghao.com 通过“googlegroups.com”
发件人当地时间: 发送时间 22:31 (GMT+08:00)。发送地当前时间：上午9:04。 ✆
pansz
pan.shizhu # gmail.com
发件人当地时间: 发送时间 08:35 (GMT+08:00)。发送地当前时间：上午9:15。 ✆
对于 pypy