给Bruce Eckel的回复
吴同
我将主要针对Bruce Eckel的Blog《
Python 3K还是Python 2.9?》中的每一部分进行回答。
并发处理：看来现在我们很高兴在 这里所找到的。我很期待着基准测试可以显示PP(译注：Parallel Python)或类似(或者不类似！)的解决方案确实可以提高性能。另一方面，我想看到的探索是：将这样的一个解决方案集成到一个存在的web框架中(也许是作为WSGI中间件)这样web应用可以有一种简单的方法来使用，而无须重新设计自已的架构。
Eggs和Easyinstall标准化: 从回复中可以看出之所以这些特别的解决方案还未被标准化的原因很清楚－－它们最容易受到争议。不管怎么样这只是库的问题与3.0没有关系。我希望有人可以改进Phillip Eby的工作。我很乐意接受某些东西到标准库中去，但是我自已没有时间去写：由于某些原因我不是这种工具的主要听众。
更好的应用程序部署支持：同样，库的问题，我不能做很多关于－－我没有时间自已来做并且我不喜欢告诉别人做什么(显然我也不喜欢自已告诉自已做什么)。
去掉self：我想这一点在回复中已经被强调了；它不象你想象得那么简单，并且还有一个巨大的好处就是将方法(method[注1])可以统一解释为函数(译注：原文不太明白，作了简化。)在Ruby中，所有东西都是方法(method)或匿名块(anonymous block)，不存在“自由函数”。Python采用互补(complimentary)的方案，将函数视为第一类公民。两种方法都是完备的，然后它们是不兼容的，你不能简单地将一种变化到另一种。(我个人觉得对于显示self的批评大概与Python中空白的使用的批评相当。)
透明连接到UI语言：同样，库的问题。我同意Tk过时了，不过它仍然有一个追随者，并且IDLE被支持得很好。备选方案已经有了，象PyQt、PyGTK、或wxPython，它们都有着特别的优点和缺点，因此很难进行选择(另外，把其中一个选入标准库所产生的政治影响可能会损害Python和未被入选的备选方案)。然而，看上去Bruce认为这些都是过时的，并且我们应该期待下一代的解决方案。但是选择哪个呢？在我看来这种方法太早了，我们无法知道这些东西将会戏剧性地进化还是有些可能消亡。
这需要有人能够奉献，愿意发布一系列的快速体验版本，并且有一定的用户基础。对于Python 3000来说它不是一个合适的项目－－尽管名字古怪，它主要是对语言本身进行保守的革新，集中在修正一些顽固的缺陷上，而这些缺陷可能只能通过打破向后兼容性来进行修复。(那些不需要打破向后兼容性的缺陷可以改良的方式被修复，但是有些地方刚好不能以这种方式进行修改。)
库支持(“智能库”)：这是相当不着边际的部分，大部分让我无法理解。再也不需要重读文档？看上去只是一厢情愿的想法。没有什么替代物可以理解你正打算做的，而且这里的"smart(智能)"似乎是洞查(clairvoyance)的同义词。然而，Bruce猜对了一件事：我正在鼓励那些想要探索这样事情的人们去生成绝大部分正打算被使用的参数注解（make the most of argument annotations, which are waiting to be used）。
组件支持：我猜这部分是引自一个我不熟悉的背景(Java用得不多)，因为在这个标题之下的与事件处理的关系让我完全莫名其妙。我似乎想起Java在支持“重量级”组件上有几次错误的尝试－－但是也许现在在那个世界已经达成了一致？我想那将是一种有用的体验把你所想要的(无论是什么)创建为一种附加库，我相信这已经在Java中是最多数的状态。
支持DSL生成：这意味着不同的东西对不同的人。我个人来说，我相信Ruby群体滥用了这一术语。就我看来，那位指出Python拥有DS库而不是DS语言的绅士恰好击中了要害。这是同一问题两种不同的解决方式的又一示例，它们是互补的并且不易统一的。
[注1]译注：这里我想method(方法)是指class(类)的成员函数。它是为了有别于简单的与类无关的函数。
原文链接
并发处理：看来现在我们很高兴在 这里所找到的。我很期待着基准测试可以显示PP(译注：Parallel Python)或类似(或者不类似！)的解决方案确实可以提高性能。另一方面，我想看到的探索是：将这样的一个解决方案集成到一个存在的web框架中(也许是作为WSGI中间件)这样web应用可以有一种简单的方法来使用，而无须重新设计自已的架构。
Eggs和Easyinstall标准化: 从回复中可以看出之所以这些特别的解决方案还未被标准化的原因很清楚－－它们最容易受到争议。不管怎么样这只是库的问题与3.0没有关系。我希望有人可以改进Phillip Eby的工作。我很乐意接受某些东西到标准库中去，但是我自已没有时间去写：由于某些原因我不是这种工具的主要听众。
更好的应用程序部署支持：同样，库的问题，我不能做很多关于－－我没有时间自已来做并且我不喜欢告诉别人做什么(显然我也不喜欢自已告诉自已做什么)。
去掉self：我想这一点在回复中已经被强调了；它不象你想象得那么简单，并且还有一个巨大的好处就是将方法(method[注1])可以统一解释为函数(译注：原文不太明白，作了简化。)在Ruby中，所有东西都是方法(method)或匿名块(anonymous block)，不存在“自由函数”。Python采用互补(complimentary)的方案，将函数视为第一类公民。两种方法都是完备的，然后它们是不兼容的，你不能简单地将一种变化到另一种。(我个人觉得对于显示self的批评大概与Python中空白的使用的批评相当。)
透明连接到UI语言：同样，库的问题。我同意Tk过时了，不过它仍然有一个追随者，并且IDLE被支持得很好。备选方案已经有了，象PyQt、PyGTK、或wxPython，它们都有着特别的优点和缺点，因此很难进行选择(另外，把其中一个选入标准库所产生的政治影响可能会损害Python和未被入选的备选方案)。然而，看上去Bruce认为这些都是过时的，并且我们应该期待下一代的解决方案。但是选择哪个呢？在我看来这种方法太早了，我们无法知道这些东西将会戏剧性地进化还是有些可能消亡。
这需要有人能够奉献，愿意发布一系列的快速体验版本，并且有一定的用户基础。对于Python 3000来说它不是一个合适的项目－－尽管名字古怪，它主要是对语言本身进行保守的革新，集中在修正一些顽固的缺陷上，而这些缺陷可能只能通过打破向后兼容性来进行修复。(那些不需要打破向后兼容性的缺陷可以改良的方式被修复，但是有些地方刚好不能以这种方式进行修改。)
库支持(“智能库”)：这是相当不着边际的部分，大部分让我无法理解。再也不需要重读文档？看上去只是一厢情愿的想法。没有什么替代物可以理解你正打算做的，而且这里的"smart(智能)"似乎是洞查(clairvoyance)的同义词。然而，Bruce猜对了一件事：我正在鼓励那些想要探索这样事情的人们去生成绝大部分正打算被使用的参数注解（make the most of argument annotations, which are waiting to be used）。
组件支持：我猜这部分是引自一个我不熟悉的背景(Java用得不多)，因为在这个标题之下的与事件处理的关系让我完全莫名其妙。我似乎想起Java在支持“重量级”组件上有几次错误的尝试－－但是也许现在在那个世界已经达成了一致？我想那将是一种有用的体验把你所想要的(无论是什么)创建为一种附加库，我相信这已经在Java中是最多数的状态。
支持DSL生成：这意味着不同的东西对不同的人。我个人来说，我相信Ruby群体滥用了这一术语。就我看来，那位指出Python拥有DS库而不是DS语言的绅士恰好击中了要害。这是同一问题两种不同的解决方式的又一示例，它们是互补的并且不易统一的。
[注1]译注：这里我想method(方法)是指class(类)的成员函数。它是为了有别于简单的与类无关的函数。
原文链接
类似资料：