可爱的 Python：JPython 和 Python for .NET内幕-2

look_w

Mertz ：照您看，JPython 比 CPython好在哪里呢？      
Bock ：JPython提供了对其底层实现语言的完整访问。在大多数（可能所有）基于 C的脚本语言中，C 函数必须封装在用来将 C函数暴露给脚本语言的一层简单的代码中，这里存在一些好的工具，例如SWIG，来将这个封装器代码的创建自动化。但 JPython根本就不需要封装器。所有曾经编写过的 Java 代码都可直接从 JPython使用，集成是双向的。以 JPython 定义的类和实例可以传递给Java，就如同它们是一般的 Java 类和实例那样（它们也确实如此）。      
嵌入／扩展 API 使从应用程序或模块中对 JPython对象的访问相当精确。这一优点部分来自于 JPython 和 Java都是面向对象的语言这一事实。Jim 利用了该事实的这一重要优点。
Warsaw ：CPython 欠缺的是对世界上大量 Java代码的访问。如果需要使用 Java 库，JPython就是答案。反过来说，当然，JPython 也没有对世界上所有现有 C库的简易访问。Finn 已完成了通过 JNI 集成如 Tkinter 和 POSIX模块这类事物的工作，但那些在 JPython中总是非标准的，因为我们希望保留 100% 纯 Java 认证。      
Mertz：依您所见，JPython 的缺点有哪些呢？      
Finn Bock ：JPython 只提供对 Java代码的访问，而不提供对所有现有 C 模块的访问。因此每个以 C 实现的Python 模块都必须用 Java 重新实现。而 CPython 则有许多模块。      
另外，对于嵌入／扩展 API，除了源代码之外没有任何文档。
Mertz ：您是否在寻找 JPython 优于纯 Java的优点？      
Warsaw ：我想我们已经谈了许多这方面的内容。但现在让我们谈谈JPython 的性能问题。因为 JPython 实现了 Python 的动态语义，所有JPython带有相当广泛的运行时。这对于某些应用程序有性能影响。例如即时编译器和Hotspot 技术这样的标准 Java优化可以大大减轻这样影响（八个月前的基准显示，使用支持 JIT 的JVM，JPython 1.1 可以达到，有时还会超过 CPython 1.5.2速度）。我们将更新这些基准结果，并在推出 JPython之后集中在性能问题上。      
但与 CPython 一样，您总能用 Java重写应用程序中的性能关键部分。
Mertz：您认为 JPython 的使用有多广泛？      
Warsaw ：我想它的使用正在变得越来越广泛。人们逐渐发现它对于技术成功非常关键。JPython对于各种任务都有价值，从为最终用户提供平易近人的脚本创建环境，到简化为Java 库和应用程序创建测试框架。此时 JPython最大的遗憾就是它需要更多宣传。我希望这篇文章能在这一方面提供帮助。      
Mertz ：您是否认为 JPython 是试图跟上 CPython的尝试？      
Bock ：是的。现在，JPython正尝试赶上它。几乎所有新的特性都首先添加到 CPython。（当然，JPython确实在 CPython 之前具有字符串方法）。JPython 有不足之处是因为CPython 比 JPython 有多 15 倍的核心开发者。但即使这样，JPython版本中存在 CPython 2.0 中几乎所有新的特性。      
但我认为实际上它们几乎不相上下，即使在现实世界中，谁也不比谁好多少。
Warsaw ：我坚决相信在语言级别上，JPython 和CPython 应该完全兼容。在不可能的情况下，Guido确定差异是否与实现相关，或者哪一种实现是“多错”的。我希望看到CPython 和 JPython 最终成为同等的，JPython 在某些方面推动 CPython开发和 CPython 推动 JPython 开发一样。      
当前它的一个示例就是 Unicode 支持。JPython 已经是全部 Unicode化了。另一个示例是类型／类划分。在 CPython中，您可以有一些内置类型，例如字符串、字典、列表和数。还有类和实例。内置类型不能继承。更让人困惑的一点是，实例既有类型又有类。首先弥补 JPython中的这一缺憾更容易些，因为其面向对象实现。
Mertz ：对于 JPython 和 CPython之间的不兼容性您是怎么认为的？      
Warsaw ：在事物工作的方法上有许多细小的差异。它们都在JPython的文档中进行了大致说明。某些作为提供语言定义的可接受差异分类，某些指出某个或其它实现应该被修正的地方。大多数都非常次要。      
Bock ：某些模块还没有或者无法以 JPython实现。某些模块又只能作为 JNI模块实现，类似的模块在部署环境中是没有用的。      
Bock ：实际上，当我移植自己的脚本和程序（与IDLE、PySol 和 PMW工具箱一起）时，我遇到的问题不是无用信息收集的随机回收或缺少_del_method。它们是其他人以前没有遇到过的小问题，例如 CPython行为。      
Warsaw ：下一个版本的 JPython 将与 Python 2.0语言定义兼容，因此最大的变化将在库中。CPython 发行版中任何以纯Python 编写的标准库模块都应该是可移植的。C扩展模块不行，除非它们特别通过 JNI 网桥集成或以 Java重新实现。任何大量使用 Java API 的 JPython 应用程序在移植回 CPython时都将经过一段艰难时期。      
另一方面，两种系统的库中有许多公共功能。在有足够深谋远虑的前提下，可以将兼容性层构建到应用程序中。
Mertz ：对于 JPython今后的方向有什么想法吗？      
Warsaw ：我们已经基于公用 JPython 1.1发行版创建了 JPython 后继者"Jython"。这样做是为了确保项目的长久性和稳定性。依据 CNRI 的JPython 1.1.x 许可证实现了所有这些。我们将整个开发过程移到了SourceForge，并使用对 CPython 非常合适的相同开放过程管理它。Finn和我两人无疑要参与 Jython 未来的开发；Jython 将使用 OSI 核准的CPython 2.0许可证发行。它与您将获得的“正式”派生很接近，所以当前的 JPython社区应该确信 Jython与它永远不会相差太多。我们希望它们最终都能迁移到 Jython。      
现在代码仍处在试验阶段，但 Finn 和我将为 Jython 2.0发行版（已经包含了 Finn 的勘误表）致力于建立几个技术性里程碑。CPython 2.0具有增强的指派和扩展打印等特性（很快还将带有列表理解）。我们已集成了免费的Apache Jakarta OROMatcher代码，消除了双许可证的需要，并修正了许多错误。我不知道 Jython 2.0的第一个 alpha 发行版何时出现，但当前所有代码都在 SourceForge CVS树中获得。