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代码都写成

   1 try:
   2    foo()
   3 except:
   4    ...

• 的话，你也可能中招，因为sys.exit()的退出方式就是抛一个异常。如果你foo()有逻辑在一定情况下调用sys.exit来退出的话，你会发现这个异常被你抓掉了。。。

所以我现在养成习惯，代码都写成：

   1 try:
   2    foo()
   3 except Exception:
   4    ...

而更多的方法，比如time.sleep，文档压根就不告诉你，它可能会抛异常。

总之，越来越多的“懂OO的java工程师“进入python领域，导致python越来越差劲

• 不要老是这样说吧，不能因噎废食，我看GTK库的C语言接口时，发现实例方法在C中的实现无非是将this struct一致作为函数第一个参数而已。
  • 你要是在Python中，明明可以写成socket.read(length)的，非要写成read(socket,length)，然后方法名又会冲突，又要写成socket_read(socket,length)或是socketlib.read(socket,length)，不成了胡折腾了吗，呵呵
  • 我想起了程序员A，发现Event、Observer很好用很灵活（那个面向事件面向消息编程嘛），就所有的调用都bindEvent再那个triggerEvent，明明只需要一个callback就解决了，非说Event更灵活更具可扩展性就像那些刚看了些OO设计模式的，就在10行代码内用了20种设计模式，这就是那些"懂OO的Java程序员"干的事
  • 然后另一个程序员B，看了些Lisp，然后就一个劲的在python中lambda map reduce filter ，明明用Class，用对象实例来表示更方便的，非要把变量放到closure中，然后就像个黑盒子一样调方法。。。。然后这些程序员还喜欢不用if else，非要用andor什么的。悲催啊

Python中的OO和lambda确实实现的不咱地，有谁能解释下__new__与__init__的功能？？ 这方面Ruby又是一个好的学习对象，Ruby比Java更OO，但更具有一致性，比如new也是一个方法（Ruby中的说法是向对象发送一个new的消息，又是面向消息嘛，呵呵）

• 我喜欢Ruby的一个原因是它其实像Lisp+Smalltalk。说起来，论OO特性，Python没地位，论FP特性，Python也没地位，论标准库，Python的工具库很多，但标准库似乎有些Out。剩下的只有Python语法简单了，但Python还有神马的元编程，多继承，我我我。。。

所以用Python，即不要太OO，也不要太FP，因为它在这两方面都不擅长（我只说不要太OO，太FP，不是说不要OO，不要FP哦，呵呵）。也不要指望Python运行速度多快，在这方面我已经开始使用Go语言了。 Keep it simple，才是Python之禅！^O

依云 :中文问题!

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规则，新手往往要花很长时间研究这个例子究竟是怎么错的：

   1 a = 1
   2 def f():
   3   print a
   4   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 目前为止主要用于服务器端，正因为解释型语言都不可能真正意义上的加密源代码，所以只有部署在服务器端能避免这个问题。

对于 pypy

• Leo Jay python.leojay# gmail.com

发件人当地时间: 发送时间 15:12 (GMT+08:00)。发送地当前时间：下午5:05。 ✆ 回复: [email protected]

• ~zw g pekingmaster# gmail.com
  • 大家对Py3都是一边倒说好呀。但是，有牛人好像对Py3很有意见呢，这又怎么说？

  • http://lucumr.pocoo.org/2011/12/7/thoughts-on-python3/

• ~ Leo Jay python.leojay# gmail.com
  • 我看还早着呢。对CPython的第三方库支持不好是硬伤。pypy之于python就像mono之于.net，openjdk之于java，大家都说他们好，但都叫好不叫座，真正用的时候，你总是时不时会发现有那么一些地方跟原版兼容性有问题

反馈

创建 by -- ZoomQuiet [2011-12-21 09:09:06]