PYTHON: A PROGRAMMING LANGUAGE FOR SOFTWARE INTEGRATION AND DEVELOPMENT M. F. SANNER The Scripps Research Institute 10550 North Torrey Pines Road, La Jolla, CA-92037 sanner@scripps.edu Over the last decade we have witnessed the emergence of technologies such as libraries, Object Orientation, software architecture and visual programming. The common goal of these technologies is to achieve software reuse. Even though, many significant advances have been made in areas such as library design, domain analysis, metric of reuse and organization for reuse, there are still unresolved problems such as component inter-operability and framework design[1]. We have investigated the use of interpreted languages to create a programmable, dynamic environment in which components can be tied together at a high level. This work has demonstrated the benefits of such an approach and has taught us about the features of the interpreted language that are key to a successful component integration. The problem One of the challenges in bio-computing is to enable the efficient use and inter-operation of a wide variety of rapidly-evolving computational methods to simulate, analyze, and understand the complex properties and interactions of molecular systems. In our laboratory we investigates several areas, including protein-ligand docking, protein-protein docking, and complex molecular assemblies. Over the years we have developed a number of computational tools such as molecular surfaces, phenomenological potentials, various docking and visualization programs which we use in conjunction with programs developed by others. The number of programs available to compute molecular properties and/or simulate molecular interactions (e.g., molecular dynamics, conformational analysis, quantum mechanics, distance geometry, docking methods, ab-initio methods) is large and growing rapidly. Moreover, these programs come in many flavors and variations, using different force fields, search techniques, algorithmic details (e.g., continuous space vs. discrete, Cartesian vs. torsional). Each variation presents its own characteristic set of advantages and limitations. These programs also tend to evolve rapidly and are usually not written as components, making it hard to get them to work together. The “traditional” solution Typically, researchers have been using tools such as AWK and shell scripts to make such programs work together. If that approach appears tempting initially, it has many inherent problems and limitations that will surface in the long run. These include, a very low level of inter-operability: i.e. usually data is transferred between programs using files or pipes allowing only inter-operation at the program level rather than the function level or at least functionality level. This makes its difficult, for instance, for a molecular dynamics code to use some third party electrostatic or molecular surface calculation package to derive a term used to drive the simulation, or to use someonersquo;s visualization program tools to steer the simulation or monitor or play back trajectories. Such developments usually require substantial coding and often access to and understanding of the source code. Such an approach also requires the creation of a large number of interfaces between different tools. This makes it very hard to incorporate new methods into the tool set and therefore stifles the researcherrsquo;s creativity. The level of code reuse offered by this approach is very low. For instance, every program operating on molecules will need to implement its own parser for different molecular file formats, each having its own bugs and weaknesses and each requiring coding effort. Finally, this approach often lead to very large scripts that are difficult to maintain, extend and debug. Other solutions: Visual programming, specialized software suites ... The frustration of developing under these conditions has prompted us to investigate better methods for developing code and integrating computational methods. Our first approach was based on using AVS (Advanced Visualization System, from AVS Inc.). This environment has proven very useful for us over the last ten years, in terms of code reuse and capturing developments done by a set of transient collaborators, typically post doctoral fellows who spend a few years in the laboratory before moving on. We have also encountered some limitations. AVS is a data-flow driven computation and visualization environment that comes with a large number of processing modules for a wide variety of operations such as: data input, image processing, surface and volume rendering, etc. These modules can be linked together graphically using a network editor to create a processing stream for a particular visualization or computation. It also offers a mechanism for adding custom- designed modules for new computational methods. AVS users roughly fall into three classes distributed in a pyramid. At the high end is the module programmer, typically writing C programs and making this code available as AVS modules. The second, and larger class of users, are those who produce their own networks using existing modules. Although networks do not have constructs for loops or conditional execution, many visualizations can be done at this level without writing a single line of code. The third, and largest class of users, are those who use their own data with an existing network. One of the reasons AVS has worked well for us is probably due to this visual programming paradigm creating this intermediate class of users which fits quite well scientists in need of custom visualization who do not want to become programmers. Of course AVSrsquo; modular nature promotes code reuse that leads to rapid prototyping. This has enabled the scientist to concentrate on the visualization process rather than the program used to visualize the data. However, molecular modeling and bio-molecular visualization pose many
剩余内容已隐藏，支付完成后下载完整资料
PYTHON：用于软件整合与开发的编程语言
Institute 10550 North Torrey Pines Road, La Jolla, CA-92037 sanner@scripps.edu
在过去十年中，我们见证了库、面向对象、软件架构和视觉编程等技术的出现，。这些技术的共同目标是实现软件重用。尽管在库设计，域分析，重用度和组织重用等领域取得了许多重大进展，但仍然存在未解决的问题，如组件交互操作和框架设计[1]。我们已经尝试使用解释型语言来创建一个可编程的动态环境，其中组件可以在高层次上联系在一起。这项工作已经证明了这种方法的好处，并向我们展示了解释语言的特征，这些特征是组件集成成功的关键。
一个在生物计算领域中的具有挑战性的问题是通过有效的利用和交互协作各种快速演化的计算方法来模拟，分析和了解分子系统的复杂性质和相互作用。在我们的实验室，我们研究了几个领域，包括蛋白质配体对接，蛋白质-蛋白质对接和复杂的分子装配。多年来，我们开发了许多计算工具，如分子标记，表面现象，各种扩展和可视化程序，我们与其他人共同使用这些来开发使用。这些用于计算分子性质和/或模拟分子相互作用（例如分子动力学，构象分析，量子力学，距离几何，对接方法，从头开始的方法）的程序的数量很庞大而且增长迅速。此外，这些程序具有许多风格和变化，使用不同的力场，搜索技术，算法细节（例如，连续空间与离散的空间，笛卡儿扭转）。每个变体都有自己的优点和局限性。这些程序也倾向于快速演化，通常不会被写成组件，使得它们很难一起工作。 “传统”解决方案下，研究人员一直使用AWK和shell脚本等工具来使这些程序一起工作。这种方法最初似乎是诱人的，但从长期来看，它有许多固有的问题和局限性。这些问题包括非常低的交互操作水平：即通常使用文件或管道在程序之间传送数据，从而只允许在程序级别而不是功能级别或至少功能级别进行交互操作。这使得类似分子动力学的代码难以使用一些第三方静电或分子表面的计算软件包来导出用于驱动模拟的术语，或者使用某人的可视化程序工具来引导模拟或监视或播放轨迹。这种开发通常需要大量编码，并且经常访问和理解源代码。这种方法还需要在不同工具之间创建大量接口。这使得很难将新方法纳入工具集，从而扼杀了研究者的创造力。这种方法提供的代码重用级别非常低。例如，分子上运行的每个程序都需要为不同的分子文件格式实现自己的解析器，每一个都有自己的错误和缺点，每个都需要编码工作。最后，这种方法通常会产生非常大量的难以维护，扩展和调试的脚本。其他解决方案：视觉编程，专业软件套件...在这些条件下开发的挫折促使我们研究更好的开发代码和集成计算方法的方法。我们的第一种方法是基于使用AVS（来自AVS公司的高级可视化系统）。在过去十年中，这种环境已被证明对我们来说非常有用，在代码重用和捕获一组瞬时协作者（通常是在实验室中花了几年时间的博士后研究员）之前进行的开发。我们也遇到了一些限制。 AVS是一种数据流驱动的计算和可视化环境，具有大量用于各种操作的处理模块，例如：数据输入，图像处理，面和体绘制等。这些模块可以使用网络编辑器，用于为特定的可视化或计算创建一个处理流。它还提供了一种机制，用于为新的计算方法添加定制设计的模块。
AVS用户大致分为三类，形似金字塔。在高端是模块程序员。通常编写C程序并将此代码用作AVS模块。第二，也是更多的一类用户是使用现有模块生产自己的网络的用户。虽然网络没有循环或条件执行的构造，但是可以在此级别完成许多可视化，而无需编写单行代码。第三个也是最大的用户类别是那些使用自己的数据与现有网络的用户。 AVS为我们工作良好的原因之一可能是由于这种可视化编程范例，创建了一种中级用户，这很适合科学家这种需要自定义可视化而不想成为程序员的人。当然，AVS模块化的性质促进了代码重用，能够快速进行原型设计。这使科学家能够专注于可视化过程，而不是用于可视化数据的程序。然而，分子建模和生物分子可视化为数据流环境提出了许多具有挑战性的问题。分子具有高水平的内部组织，通常需要在其上运行的程序中再现。这并不总是与这些环境中通常可用的简单数据类型兼容。还存在数据复制和模块间通信的问题。但是，我们认为AVS中最严格的限制是缺乏脚本功能。 AVS命令语言界面（CLI）仅由一组命令组成，而且它仅开发了内核功能的一部分，从而产生了一些严重的限制。我们通过在AVS模块中嵌入Python解释器来解决这些问题，从而增加了脚本功能[1]。商业和学术分子建模包比AVS更具体地解决了这些问题，然而，这些包中的大多数是单片程序，仅提供一些有限的选项来改变可视化的风格或扩展程序来接受新的数据类型或做新计算。由于我们的任务之一是调查新的计算方法和可视化，它们似乎不是正确的工具。以语言为中心的方法和解释语言程序通常以“以自我为中心”的方式发展，这意味着它们被写为独立单位，旨在解决给定的履行任务的问题。一些程序，如AVS，旨在通过添加可以封装新计算方法的新模块进行扩展，但这必须在程序框架内完成。而且由于程序本身是专门的，这一定会造成问题。为了解决这个问题，我们决定尝试以“以语言为中心”的方法。我们使用高级语言作为我们框架的核心。而不是编写程序，我们现在通过实现特定功能的模块或组件扩展这种语言。高级语言是将模块和组件结合在一起的“粘合剂”，以快速创建专门的应用程序。在某种意义上，语言成为一个“脚本框架”，可以快速原型化新的应用程序。开发语言的扩展模块对应于尽可能延迟代码的专业化。我们认为，一种解释性语言将提供这种方法所需的灵活性，交互性和可扩展性，我们开始使用三种最流行的解释语言：Perl，TCL和Python。有许多文章将这三种语言相互比较，以及编译语言如C，C 和Java [参见http://www.python.org/doc/Comparisons.html以获取文章列表）。
经过对这些不同语言的一些实验，我们得出“所有解释语言不是平等的”，而且每个语言都有其特定的优点和缺点。当然，它们都提供了一个可交互式，灵活，可扩展和可嵌入的脚本框架，但是在一个或另一个对于给定任务而言更为引人注目的是在风格和哲学方面存在差异。 Perl拥有最大的用户群，对于短脚本来说有着令人惊讶的出色表现，这些脚本做了大量的工作，不幸的是，理解它也是相当具有挑战性的。这种语言为常见的面向应用程序的任务提供了良好的支持，而Python的优雅而不是过于隐秘的语法强调了对常用编程方法的支持，并提高了代码可读性，从而提高了可维护性。 Tcl，像Python一样可以用作扩展语言和独立的编程语言，但它对数据结构的支持相当薄弱（传统上一切都是字符串）。此外，8.0版之前缺少模块化名称空间，妨碍了大型程序的开发。所有这些语言跨越多个平台，通常比Java提供更多的平台独立性。它们都可以以C或C 扩展。我们采用了Python语言基于很多原因，包括：它的简洁和几乎伪代码的语法;其模块化;其面向对象设计;其分析，调试，反思，内省和自我文档功能;以及数字扩展的可用性，允许高效存储和操纵大量的数字数据。 Python与任何其他解释语言一样好，但另外也可用于开发大量的扩展组件。 Python是一种解释型，交互式的面向对象编程语言。它提供高级数据结构，例如列表和关联数组（称为字典），动态类型和动态绑定，模块，类，异常，自动内存管理等。它具有非常简单和优雅的语法，而且是一个强大的和通用编程语言。它是由Guido van Rossum于1990年设计的。像许多其他脚本语言一样，它是免费的，甚至可以用于商业目的，它可以在几乎任何现代的计算机上运行。一个python程序由解释器自动编译成平台无关的字节码，然后被解释。我们在linux，Windows NT，98,95，IRIX，SunOS，OSF下运行Python编写的未修改的组件。 Python是模块化的。内核非常小，可以通过导入扩展模块进行扩展。 Python发行版包括一些不同的标准扩展库（一些用Python编写，另一些用于C或C ），用于从字符串操作和类Perl的正则表达式到图形用户界面（GUI）生成器的操作，包括与Web相关的实用程序，操作系统服务，调试和分析工具等。可以创建新的扩展模块，以使用新的或旧的代码来扩展语言。我们在下面介绍这些扩展功能。有大量的扩展模块已被开发并由Python用户社区的成员分发。这些扩展模块有时称为“软件包”或组件，包括以Python编写的SQL数据库管理器GADFLY; PIL，Python成像库; FNORB和OmniBorker，以Python编写的CORBA兼容对象请求代理（ORB）; Gendoc，一种自动化文档工具;和Numeric Python，仅举几例。
Python最好的资源和可用的书籍可能是Python网站（http://www.python.org）。它提供访问代码，文档，包，文章，邮件列表等功能。还值得一提的是最近创建的biopython.org网站，一个计算生物学和化学的协作软件，非常像bioperl。最后，值得一提的是，除了Python解释器的C实现之外，还有一个称为JPython的100％纯Java实现，允许将Python用作Java世界中的编程解释语言。该解释器允许实例化Java类，Java代码可以调用Python代码。原生扩展首先需要在Java世界中提供，然后才能在JPython中使用。 Python数字扩展Numeric Python是用于数据的高效存储和数据并行操作的扩展模块。使用此模块，许多简单的操作在Python中本来很慢的程序可以非常有效地执行（基本上与C一样快），而无需在C中实现代码。该模块通常允许我们在Python中编写扩展（使用Numeric）对于我们的目的来说足够有效，不需要用C或C 重新编码。例如，如果构成分子的N个原子的坐标存储在称为“坐标”的Nx3个浮点值的矩阵中，像以下Python代码中所示的操作一样，变得语法简单，效率高，就好像它们使用的是C或C 语言：
使用3向量T平移分子。这说明了数据的并行操作，将3矢量添加到每隔3个坐标中的适量
Coordinates gt;gt;gt; Coordinates = Coordinates T –
计算重心的分子。首先对所有数值进行求和，同时折叠数组的第一维，然后除以原子数。
gt;gt;gt; import Numeric gt;gt;gt; g = Numeric.sum(Coordinates) / len(Coordinates) –
计算从所有原子到给定3D点的距离P
gt;gt;gt; d = Coordinates - P gt;gt;gt; # now sum over the 2nd dimension and take the sqrt gt;gt;gt; d = Numeric.sqrt(Numeric.sum(d*d, 1))＃现在总计第二维，并取sqrt gt;gt;gt; d = Numeric.sqrt（Numeric.sum（d * d，1））
在使用解释语言时，常常担心在性能方面所消耗的成本。我们知道，首先，我们对于我们需要的地点，时间和性能有一个错误的概念。此外，Python代码运行的合理性能足以满足许多常见任务。最后，使用数字扩展有助于保持良好的性能，即使使用大量数字。我喜欢给出的一个例子是说明这些点是我们第一个开发为C扩展的Python的PDB解析器，因为尽管我们的Python代码不够有效。但我们写来读取PDB文件的C扩展最终变得非常复杂，变得难以维护和扩展。所以我们决定开发一个Python版本，其性能与C版本非常接近，用于解析PDB文件，树状结构和计算连接。它还小得多，更简单，易于维护，并且与平台无关。我们认为，小的性能损失是非常值得的相对于我们在灵活性和可移植性方面获得的收益。从那时起，我们将对Python中的所有新扩展进行原型化，然后对其进行概要分析，然后再决定哪些部分真正需要在C或C 中重新实现。 Python作为一个集成工具正如我们前面提到的，所有现代解释语言的一个关键特征就是它们的可扩展性。我想简要回顾一下我们基于Python的脚本框架可以集成旧代码并扩展新功能的不同方法。基本上有三种方法可以在此脚本框架中添加新功能：通过在Python中实现它，通过“包装”现有代码，或通过创建具有一些通信功能的现有代码的接口。
- 在Python中实现功能：这是我们进行的所有新开发的首选方法。实际上，对于还没有编写Python的高级本质的代码，已经可以使用的扩展使得它在Python中比在C或C 中更容易实现。即使有一些代码已经存在，我们决定在Python中重新实现一些情况。当Python中的重新编码需要相对较少的代码（这并不罕见）），并且Python代码的性能预期是可以接受的。这种方法提供了平台独立性的主要优点。
- 包装现有的C，C 和Fortran代码：在许多情况下，在Python中重新实现一些旧代码是没有意义的。然而，最好从Python访问这个代码。这需要“包装”Python的旧代码。让我们考虑以下简单的例子：我们有一个函数“foo”，它将一个整数作为参数返回一个浮点数。在Python的世界中，整数和浮点数是对象。为了能够从Python调用函数foo，我们必须在C中编写一个函数：将Python对象作为参数;从该对象中提取整数值;调用该整数值的函数foo;将返回的float包装到表示float的Python对象中;并最终将该对象返回给解释器。这个代码叫做“包装代码”。一旦我们拥有包装器代码，我们可以与函数foo一起编译它，并创建一个共享对象（Windows环境中的dll），然后将其导入到Python解释器中。当然，这个扩展是依赖于平台的。
- 使用SWIG，简单包装器接口生成器（http：// www.swig.org），可以将包装代码的这个过程在很大程度上自动化。 SWIG可以为几种解释语言（如T
剩余内容已隐藏，支付完成后下载完整资料
资料编号：[141165]，资料为PDF文档或Word文档，PDF文档可免费转换为Word
以上是毕业论文外文翻译，课题毕业论文、任务书、文献综述、开题报告、程序设计、图纸设计等资料可联系客服协助查找。
