可爱的 Python:JPython 和 Python for .NET 内幕 选择自 Pythonfan 的 Blog
来源:互联网 发布:赠送花园补充协议 知乎 编辑:程序博客网 时间:2024/05/02 01:11
可爱的 Python:JPython 和 Python for .NET 内幕
采访创始人
David Mertz, Ph.D.
总裁,Gnosis Software Inc.
2000 年 12 月
David Mertz 采访了 JPython 和 Python for .NET 的开发者 MarkHammond、Finn Bock 和 Barry Warsaw。他从 Mark那里了解到一些有关微软开发的最新独家新闻内幕(当然所有内容都在保密合同限制内),并从 Finn 和 Barry 那里了解到有关 JPython和他们将要发布的 Jython 项目的一些信息。
尽管 Python 通常等同于 CPython,但它的规范曾在其它地方实现过多次,包括在用于 Java 和 .NET的应用程序中。JPython 将 Python 源码编译成 Java 字节码,并提供了对 Java 类的透明访问。Python for.NET 是微软将要发布的交叉语言技术平台工作中的一个应用。在采访 Mark Hammond、Finn Bock 和 Barry Warsaw的过程中,我发现了有关 JPython 和 Python for .NET 是如何开发的更多信息,以及为未来这些替代 Python实现进行了哪些准备。
Python for .NET
由于在 PythonWin环境和 PythonCOM 扩展方面出色的开发,Mark Hammond 为广大 Python 程序员所熟知。出于我们钦佩 Mark的相同原因,微软也很看重他。他们决定在 Python for .NET 的实现上向他求助。据 Mark 称,Python for .NET的工作版本应该很快就可得到,现在您应该已经可以从 ActiveState 获得它的 alpha 或 beta 版(请参阅参考资料)。
David Mertz:到底什么是 Python for .NET 呢?我想我特别想知道的是 Python for .NET 与您自己对 CPython 的 PythonWin 和 PythonCOM 扩展(它们似乎能够控制 Windows 的内部)之间的关系是怎样的。
Mark Hammond:Python for .NET 是一种编译器和运行时,它在微软的 .NET 平台上实现了 Python。.NET 平台提供了一个运行时和元数据系统,它们设计成允许完整的语言互操作性,但要实现这一点,语言必须能在该运行时中使用。
例如,如果 Python 类是公用的以便 Visual Basic 程序员能够继承它,Python 类就必须以 .NET 术语而不是以 CPython 术语来实现和描述。
Python .NET 的优点只是可以与 .NET 框架互操作。这里仍然有许多缺陷,主要由于实现还不成熟而导致。但这确实只是时间的问题。我们仍处于开发和调试的 beta 阶段。
Mertz:您对现在的 Python for .NET 和 CPython 之间不兼容性问题是怎么看的?
Hammond:是啊,大多数模块还没有被实现,所以现有以 C 编写的模块还无法确切使用。如果您的目标不是 .NET 框架,最好此时不要使用 Python .NET。
Mertz:不过,Python for .NET 肯定有一些主要的优势,例如方便的语言间通信和多语言应用开发。但为什么您说比已经有的那些 -- 例如 Python+C+SWIG 要好呢(当然是假设情况)。
Hammond:就 Python+C+SWIG 目前的发展而言,应该是明显的。语言间调用永远不应该象使用 Python+C+SWIG 那样困难。但 SWIG 在许多其它方面是个了不起的产品。它揭开了 Python C 扩展编写的神秘面纱,并仅将它归到困难的行列。
将 .NET 与 COM 或 Corba 进行比较更合理一些。COM 和 Corba都提供交叉语言调用“正适用”的解决方案,而不需要任何手工参与或编译。.NET将它更进了一步,并提供交叉语言继承和异常能力。这些优点非常类似于在 Java 虚拟机下的多语言实现中发现的那些。
Mertz:Python for .NET 将 Python 脚本编译成外部虚拟机的格式。对于 .NET VM 是否将支持 Stackless 和 Vyper 的某些外来特性,例如延续性、生成器、协同程序、尾递归或延缓求值,您认为会这样吗?
Hammond:是的,从理论上说它会。但微软 Beta 协议的一些条款不允许我谈论有关性能的问题。让我们将目标只定在核心 Python 语言引用中定义的那些特性上。无用信息收集是继承的,就象在 JPython 和 JVM 中的那样。
Mertz:接下来谈谈政策主题,您认为微软为什么正在进行 Python for .NET 的开发工作呢?
Hammond:这样选择目标 .NET 的人就可使用 Python 了。微软很早就确定要参与到 Python 和其它许多语言中,以确保他们的 VM 确实是不懂语言也能够使用的。根据来自各种语言实现者的反馈意见,现在他们已经对他们的 VM 做了大量更改。
Mertz:那么 Python for .NET 的财务关系是怎样的?您付费给他们吗?或者他们付费给您?
Hammond:关于构建 Python for .NET,Greg Stein 和我与微软签有合同。该合同的条款是机密的。但我基本上为 ActiveState(Perl for .NET 实现)工作。为完成移植,我希望他们最终能与微软签定类似的合同。
Mertz:这对于 Python for .NET 附带的许可证条款方面意味着什么呢?
Hammond:它将附带 "(c) Microsoft" 说明,但它一定是可免费使用的。
Mertz:我一直在担心微软会尝试使用与“采用、扩展、废除”策略类似的专用扩展和增强。换句话说,我恐怕 Python for .NET 无法长期对 Python 真正有利。
Hammond:如果 .NET 成为一个很重要的力量,那么针对它的 Python 实现就有助于 Python,与针对 JVM 的 JPython 有助于 Python一样。
JPython
尽管 JPython是一个真正面向社区的成果,但 Barry Warsaw 和 Finn Bock 是当前两名最活跃的 JPython开发者。不幸的是,JPython 最初的开发者 Jim Hugunin不再从事其开发了。在我的网站上有关于该采访未作删节(技术性更强)的版本(请参阅参考资料)。
David Mertz:究竟什么是 JPython?
Barry Warsaw:我将用标准的营销说法来回答这个问题。
JPython 是 Python 编程语言的 100% 纯 Java 实现。它可以让用户将 Python源代码编译成 Java 字节码,并在任何 Java 虚拟机上运行产生的字节码。它是与 Java 的最无缝最平滑的集成。您可以从 Python访问所有 Java 库、构建 Applet、与 Java Bean 集成以及从 Python 中的 Java类创建子类,反之亦然。JPython 类似于 Python 而不象 Java,它可以交互使用;只需在提示上输入一些 JPython代码就能立刻看到结果。
用更简单的话来说,JPython 可以为任何一个您需要的 Java 代码编写脚本,这样转换出的代码行数比原来要少上 2 到 10 倍。因为 Python 是动态输入的语言,所以可以更快速地开发错误更少的应用,并得到灵活得多的程序。
Mertz:有关 JPython 的开发是如何开始的呢?
Warsaw:JPython 是由 Jim Hugunin 发明的,他现在为 Xerox PARC 的Aspect Oriented Programming 项目工作。我了解 Jim,他可能主要是对挑战感兴趣。Python领域中有许多人都认为这是不可实现的。Guido 自己就是一个怀疑论者。Jim 证明他们都错了!
那么既然遇到挑战,为什么还要继续开发 JPython 呢?因为它是大多数 Java 程序员不太了解的最有价值的 Java 工具。到目前为止!
Mertz:您认为是什么刺激了 JPython 的需求?
Warsaw:首先必须理解 JPython 不是 Java 的竞争对手;而是对它的最好补充。Java是静态输入的编译语言。这确保了库的输入很安全并且执行速度更快。有一个现象很有趣,就是尽管它是字节码翻译的,但大多数人还是将 Java看作一个传统的“编写-编译-运行-编辑”的程序。当然,Java 利用了软件世界的绝大部分,因此对于 Java 程序员有许多资源可用。
但相同的静态输入和传统的编程周期在人力资源方面增加了 Java 应用开发的成本。Python 在这方面绝对胜出。因为 Python是一种小而简单的语言,所以非常易于掌握。大多数有经验的程序员可以在大约一天的时间内就学习到足够的 Python 知识来提高生产力。Python的设计思想就是代码的读比写要多得多。因此 Python 源代码易于在大型团体项目中共享。
但更重要的是,Python 是非常高级的动态输入型语言。这表现在大大节约了执行任务所需的代码数量。因为使用 Python 所写的代码行数较少,可以写得更快,错误更少。对于快速应用开发这简直太棒了。
Python 还提供一个交互式解释器,这意味着您可以坐在解释器提示,导入 Java 代码,创建 Java 类实例,进行方法调用等等,所有这些都是交互式的。这在训练程序员如何使用公司 Java 库或者试验新 Java API 时是一种绝佳工具。
但以我拙见,所有程序员都应该备有 CPython 和 JPython。
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 具有增强的指派和扩展打印等特性(很快还将带有列表理解)。我们已集成了免费的 ApacheJakarta OROMatcher 代码,消除了双许可证的需要,并修正了许多错误。我不知道 Jython 2.0 的第一个 alpha发行版何时出现,但当前所有代码都在 SourceForge CVS 树中获得。
- 可爱的 Python:JPython 和 Python for .NET 内幕 选择自 Pythonfan 的 Blog
- 可爱的 Python:JPython 和 Python for .NET 内幕
- jpython的使用(Java调用python脚本)
- 可爱的Python
- 可爱的python conclusion
- 可爱的python
- 可爱的python》读书笔记
- 可爱的 Python: pydoc 和 distutils 模块
- 可爱的 Python:Curses 编程
- 可爱的 Python:使用状态机
- 可爱的python课后习题
- <Python>字典,可爱的字典
- 可爱的 Python:Python 中的 TK 编程
- 可爱的 Python:Python 中的文本处理
- 可爱的 Python:Python 中的函数编程
- [可爱的 Python]: Python 中的函数编程
- 可爱的 Python:Python中的文本处理
- AOP应用实例--Spring事务处理及其AOP框架的内幕 选择自 jwsh1984 的 Blog
- 大小端(little-endian big-endian)问题小结
- Jsond的一些操作
- 199句美剧常用口语
- 工作很累的原因 搞笑
- 孩子最怕听的10句话
- 可爱的 Python:JPython 和 Python for .NET 内幕 选择自 Pythonfan 的 Blog
- Java开源软件六大帮派
- Windows Server 2003 家族产品支持两种授权模式
- xslt中的问题:"<"(十六进制0x3C)是无效的属性字符
- 在应用中嵌入Python - lf8289的专栏 - CSDNBlog
- linux下java环境和eclipse的配置
- SQL 2005数据字段类型说明???
- 征服Python—语言基础与典型应用
- 8.1.3 在Python扩展中使用MFC