| |
| \documentclass{howto} |
| |
| \title{Python Advocacy HOWTO} |
| |
| \release{0.03} |
| |
| \author{A.M. Kuchling} |
| \authoraddress{\email{amk@amk.ca}} |
| |
| \begin{document} |
| \maketitle |
| |
| \begin{abstract} |
| \noindent |
| It's usually difficult to get your management to accept open source |
| software, and Python is no exception to this rule. This document |
| discusses reasons to use Python, strategies for winning acceptance, |
| facts and arguments you can use, and cases where you \emph{shouldn't} |
| try to use Python. |
| |
| This document is available from the Python HOWTO page at |
| \url{http://www.python.org/doc/howto}. |
| |
| \end{abstract} |
| |
| \tableofcontents |
| |
| \section{Reasons to Use Python} |
| |
| There are several reasons to incorporate a scripting language into |
| your development process, and this section will discuss them, and why |
| Python has some properties that make it a particularly good choice. |
| |
| \subsection{Programmability} |
| |
| Programs are often organized in a modular fashion. Lower-level |
| operations are grouped together, and called by higher-level functions, |
| which may in turn be used as basic operations by still further upper |
| levels. |
| |
| For example, the lowest level might define a very low-level |
| set of functions for accessing a hash table. The next level might use |
| hash tables to store the headers of a mail message, mapping a header |
| name like \samp{Date} to a value such as \samp{Tue, 13 May 1997 |
| 20:00:54 -0400}. A yet higher level may operate on message objects, |
| without knowing or caring that message headers are stored in a hash |
| table, and so forth. |
| |
| Often, the lowest levels do very simple things; they implement a data |
| structure such as a binary tree or hash table, or they perform some |
| simple computation, such as converting a date string to a number. The |
| higher levels then contain logic connecting these primitive |
| operations. Using the approach, the primitives can be seen as basic |
| building blocks which are then glued together to produce the complete |
| product. |
| |
| Why is this design approach relevant to Python? Because Python is |
| well suited to functioning as such a glue language. A common approach |
| is to write a Python module that implements the lower level |
| operations; for the sake of speed, the implementation might be in C, |
| Java, or even Fortran. Once the primitives are available to Python |
| programs, the logic underlying higher level operations is written in |
| the form of Python code. The high-level logic is then more |
| understandable, and easier to modify. |
| |
| John Ousterhout wrote a paper that explains this idea at greater |
| length, entitled ``Scripting: Higher Level Programming for the 21st |
| Century''. I recommend that you read this paper; see the references |
| for the URL. Ousterhout is the inventor of the Tcl language, and |
| therefore argues that Tcl should be used for this purpose; he only |
| briefly refers to other languages such as Python, Perl, and |
| Lisp/Scheme, but in reality, Ousterhout's argument applies to |
| scripting languages in general, since you could equally write |
| extensions for any of the languages mentioned above. |
| |
| \subsection{Prototyping} |
| |
| In \emph{The Mythical Man-Month}, Fredrick Brooks suggests the |
| following rule when planning software projects: ``Plan to throw one |
| away; you will anyway.'' Brooks is saying that the first attempt at a |
| software design often turns out to be wrong; unless the problem is |
| very simple or you're an extremely good designer, you'll find that new |
| requirements and features become apparent once development has |
| actually started. If these new requirements can't be cleanly |
| incorporated into the program's structure, you're presented with two |
| unpleasant choices: hammer the new features into the program somehow, |
| or scrap everything and write a new version of the program, taking the |
| new features into account from the beginning. |
| |
| Python provides you with a good environment for quickly developing an |
| initial prototype. That lets you get the overall program structure |
| and logic right, and you can fine-tune small details in the fast |
| development cycle that Python provides. Once you're satisfied with |
| the GUI interface or program output, you can translate the Python code |
| into C++, Fortran, Java, or some other compiled language. |
| |
| Prototyping means you have to be careful not to use too many Python |
| features that are hard to implement in your other language. Using |
| \code{eval()}, or regular expressions, or the \module{pickle} module, |
| means that you're going to need C or Java libraries for formula |
| evaluation, regular expressions, and serialization, for example. But |
| it's not hard to avoid such tricky code, and in the end the |
| translation usually isn't very difficult. The resulting code can be |
| rapidly debugged, because any serious logical errors will have been |
| removed from the prototype, leaving only more minor slip-ups in the |
| translation to track down. |
| |
| This strategy builds on the earlier discussion of programmability. |
| Using Python as glue to connect lower-level components has obvious |
| relevance for constructing prototype systems. In this way Python can |
| help you with development, even if end users never come in contact |
| with Python code at all. If the performance of the Python version is |
| adequate and corporate politics allow it, you may not need to do a |
| translation into C or Java, but it can still be faster to develop a |
| prototype and then translate it, instead of attempting to produce the |
| final version immediately. |
| |
| One example of this development strategy is Microsoft Merchant Server. |
| Version 1.0 was written in pure Python, by a company that subsequently |
| was purchased by Microsoft. Version 2.0 began to translate the code |
| into \Cpp, shipping with some \Cpp code and some Python code. Version |
| 3.0 didn't contain any Python at all; all the code had been translated |
| into \Cpp. Even though the product doesn't contain a Python |
| interpreter, the Python language has still served a useful purpose by |
| speeding up development. |
| |
| This is a very common use for Python. Past conference papers have |
| also described this approach for developing high-level numerical |
| algorithms; see David M. Beazley and Peter S. Lomdahl's paper |
| ``Feeding a Large-scale Physics Application to Python'' in the |
| references for a good example. If an algorithm's basic operations are |
| things like "Take the inverse of this 4000x4000 matrix", and are |
| implemented in some lower-level language, then Python has almost no |
| additional performance cost; the extra time required for Python to |
| evaluate an expression like \code{m.invert()} is dwarfed by the cost |
| of the actual computation. It's particularly good for applications |
| where seemingly endless tweaking is required to get things right. GUI |
| interfaces and Web sites are prime examples. |
| |
| The Python code is also shorter and faster to write (once you're |
| familiar with Python), so it's easier to throw it away if you decide |
| your approach was wrong; if you'd spent two weeks working on it |
| instead of just two hours, you might waste time trying to patch up |
| what you've got out of a natural reluctance to admit that those two |
| weeks were wasted. Truthfully, those two weeks haven't been wasted, |
| since you've learnt something about the problem and the technology |
| you're using to solve it, but it's human nature to view this as a |
| failure of some sort. |
| |
| \subsection{Simplicity and Ease of Understanding} |
| |
| Python is definitely \emph{not} a toy language that's only usable for |
| small tasks. The language features are general and powerful enough to |
| enable it to be used for many different purposes. It's useful at the |
| small end, for 10- or 20-line scripts, but it also scales up to larger |
| systems that contain thousands of lines of code. |
| |
| However, this expressiveness doesn't come at the cost of an obscure or |
| tricky syntax. While Python has some dark corners that can lead to |
| obscure code, there are relatively few such corners, and proper design |
| can isolate their use to only a few classes or modules. It's |
| certainly possible to write confusing code by using too many features |
| with too little concern for clarity, but most Python code can look a |
| lot like a slightly-formalized version of human-understandable |
| pseudocode. |
| |
| In \emph{The New Hacker's Dictionary}, Eric S. Raymond gives the following |
| definition for "compact": |
| |
| \begin{quotation} |
| Compact \emph{adj.} Of a design, describes the valuable property |
| that it can all be apprehended at once in one's head. This |
| generally means the thing created from the design can be used |
| with greater facility and fewer errors than an equivalent tool |
| that is not compact. Compactness does not imply triviality or |
| lack of power; for example, C is compact and FORTRAN is not, |
| but C is more powerful than FORTRAN. Designs become |
| non-compact through accreting features and cruft that don't |
| merge cleanly into the overall design scheme (thus, some fans |
| of Classic C maintain that ANSI C is no longer compact). |
| \end{quotation} |
| |
| (From \url{http://www.catb.org/~esr/jargon/html/C/compact.html}) |
| |
| In this sense of the word, Python is quite compact, because the |
| language has just a few ideas, which are used in lots of places. Take |
| namespaces, for example. Import a module with \code{import math}, and |
| you create a new namespace called \samp{math}. Classes are also |
| namespaces that share many of the properties of modules, and have a |
| few of their own; for example, you can create instances of a class. |
| Instances? They're yet another namespace. Namespaces are currently |
| implemented as Python dictionaries, so they have the same methods as |
| the standard dictionary data type: .keys() returns all the keys, and |
| so forth. |
| |
| This simplicity arises from Python's development history. The |
| language syntax derives from different sources; ABC, a relatively |
| obscure teaching language, is one primary influence, and Modula-3 is |
| another. (For more information about ABC and Modula-3, consult their |
| respective Web sites at \url{http://www.cwi.nl/~steven/abc/} and |
| \url{http://www.m3.org}.) Other features have come from C, Icon, |
| Algol-68, and even Perl. Python hasn't really innovated very much, |
| but instead has tried to keep the language small and easy to learn, |
| building on ideas that have been tried in other languages and found |
| useful. |
| |
| Simplicity is a virtue that should not be underestimated. It lets you |
| learn the language more quickly, and then rapidly write code, code |
| that often works the first time you run it. |
| |
| \subsection{Java Integration} |
| |
| If you're working with Java, Jython |
| (\url{http://www.jython.org/}) is definitely worth your |
| attention. Jython is a re-implementation of Python in Java that |
| compiles Python code into Java bytecodes. The resulting environment |
| has very tight, almost seamless, integration with Java. It's trivial |
| to access Java classes from Python, and you can write Python classes |
| that subclass Java classes. Jython can be used for prototyping Java |
| applications in much the same way CPython is used, and it can also be |
| used for test suites for Java code, or embedded in a Java application |
| to add scripting capabilities. |
| |
| \section{Arguments and Rebuttals} |
| |
| Let's say that you've decided upon Python as the best choice for your |
| application. How can you convince your management, or your fellow |
| developers, to use Python? This section lists some common arguments |
| against using Python, and provides some possible rebuttals. |
| |
| \emph{Python is freely available software that doesn't cost anything. |
| How good can it be?} |
| |
| Very good, indeed. These days Linux and Apache, two other pieces of |
| open source software, are becoming more respected as alternatives to |
| commercial software, but Python hasn't had all the publicity. |
| |
| Python has been around for several years, with many users and |
| developers. Accordingly, the interpreter has been used by many |
| people, and has gotten most of the bugs shaken out of it. While bugs |
| are still discovered at intervals, they're usually either quite |
| obscure (they'd have to be, for no one to have run into them before) |
| or they involve interfaces to external libraries. The internals of |
| the language itself are quite stable. |
| |
| Having the source code should be viewed as making the software |
| available for peer review; people can examine the code, suggest (and |
| implement) improvements, and track down bugs. To find out more about |
| the idea of open source code, along with arguments and case studies |
| supporting it, go to \url{http://www.opensource.org}. |
| |
| \emph{Who's going to support it?} |
| |
| Python has a sizable community of developers, and the number is still |
| growing. The Internet community surrounding the language is an active |
| one, and is worth being considered another one of Python's advantages. |
| Most questions posted to the comp.lang.python newsgroup are quickly |
| answered by someone. |
| |
| Should you need to dig into the source code, you'll find it's clear |
| and well-organized, so it's not very difficult to write extensions and |
| track down bugs yourself. If you'd prefer to pay for support, there |
| are companies and individuals who offer commercial support for Python. |
| |
| \emph{Who uses Python for serious work?} |
| |
| Lots of people; one interesting thing about Python is the surprising |
| diversity of applications that it's been used for. People are using |
| Python to: |
| |
| \begin{itemize} |
| \item Run Web sites |
| \item Write GUI interfaces |
| \item Control |
| number-crunching code on supercomputers |
| \item Make a commercial application scriptable by embedding the Python |
| interpreter inside it |
| \item Process large XML data sets |
| \item Build test suites for C or Java code |
| \end{itemize} |
| |
| Whatever your application domain is, there's probably someone who's |
| used Python for something similar. Yet, despite being useable for |
| such high-end applications, Python's still simple enough to use for |
| little jobs. |
| |
| See \url{http://wiki.python.org/moin/OrganizationsUsingPython} for a list of some of the |
| organizations that use Python. |
| |
| \emph{What are the restrictions on Python's use?} |
| |
| They're practically nonexistent. Consult the \file{Misc/COPYRIGHT} |
| file in the source distribution, or |
| \url{http://www.python.org/doc/Copyright.html} for the full language, |
| but it boils down to three conditions. |
| |
| \begin{itemize} |
| |
| \item You have to leave the copyright notice on the software; if you |
| don't include the source code in a product, you have to put the |
| copyright notice in the supporting documentation. |
| |
| \item Don't claim that the institutions that have developed Python |
| endorse your product in any way. |
| |
| \item If something goes wrong, you can't sue for damages. Practically |
| all software licences contain this condition. |
| |
| \end{itemize} |
| |
| Notice that you don't have to provide source code for anything that |
| contains Python or is built with it. Also, the Python interpreter and |
| accompanying documentation can be modified and redistributed in any |
| way you like, and you don't have to pay anyone any licensing fees at |
| all. |
| |
| \emph{Why should we use an obscure language like Python instead of |
| well-known language X?} |
| |
| I hope this HOWTO, and the documents listed in the final section, will |
| help convince you that Python isn't obscure, and has a healthily |
| growing user base. One word of advice: always present Python's |
| positive advantages, instead of concentrating on language X's |
| failings. People want to know why a solution is good, rather than why |
| all the other solutions are bad. So instead of attacking a competing |
| solution on various grounds, simply show how Python's virtues can |
| help. |
| |
| |
| \section{Useful Resources} |
| |
| \begin{definitions} |
| |
| |
| \term{\url{http://www.pythonology.com/success}} |
| |
| The Python Success Stories are a collection of stories from successful |
| users of Python, with the emphasis on business and corporate users. |
| |
| %\term{\url{http://www.fsbassociates.com/books/pythonchpt1.htm}} |
| |
| %The first chapter of \emph{Internet Programming with Python} also |
| %examines some of the reasons for using Python. The book is well worth |
| %buying, but the publishers have made the first chapter available on |
| %the Web. |
| |
| \term{\url{http://home.pacbell.net/ouster/scripting.html}} |
| |
| John Ousterhout's white paper on scripting is a good argument for the |
| utility of scripting languages, though naturally enough, he emphasizes |
| Tcl, the language he developed. Most of the arguments would apply to |
| any scripting language. |
| |
| \term{\url{http://www.python.org/workshops/1997-10/proceedings/beazley.html}} |
| |
| The authors, David M. Beazley and Peter S. Lomdahl, |
| describe their use of Python at Los Alamos National Laboratory. |
| It's another good example of how Python can help get real work done. |
| This quotation from the paper has been echoed by many people: |
| |
| \begin{quotation} |
| Originally developed as a large monolithic application for |
| massively parallel processing systems, we have used Python to |
| transform our application into a flexible, highly modular, and |
| extremely powerful system for performing simulation, data |
| analysis, and visualization. In addition, we describe how Python |
| has solved a number of important problems related to the |
| development, debugging, deployment, and maintenance of scientific |
| software. |
| \end{quotation} |
| |
| \term{\url{http://pythonjournal.cognizor.com/pyj1/Everitt-Feit_interview98-V1.html}} |
| |
| This interview with Andy Feit, discussing Infoseek's use of Python, can be |
| used to show that choosing Python didn't introduce any difficulties |
| into a company's development process, and provided some substantial benefits. |
| |
| %\term{\url{http://www.python.org/psa/Commercial.html}} |
| |
| %Robin Friedrich wrote this document on how to support Python's use in |
| %commercial projects. |
| |
| \term{\url{http://www.python.org/workshops/1997-10/proceedings/stein.ps}} |
| |
| For the 6th Python conference, Greg Stein presented a paper that |
| traced Python's adoption and usage at a startup called eShop, and |
| later at Microsoft. |
| |
| \term{\url{http://www.opensource.org}} |
| |
| Management may be doubtful of the reliability and usefulness of |
| software that wasn't written commercially. This site presents |
| arguments that show how open source software can have considerable |
| advantages over closed-source software. |
| |
| \term{\url{http://sunsite.unc.edu/LDP/HOWTO/mini/Advocacy.html}} |
| |
| The Linux Advocacy mini-HOWTO was the inspiration for this document, |
| and is also well worth reading for general suggestions on winning |
| acceptance for a new technology, such as Linux or Python. In general, |
| you won't make much progress by simply attacking existing systems and |
| complaining about their inadequacies; this often ends up looking like |
| unfocused whining. It's much better to point out some of the many |
| areas where Python is an improvement over other systems. |
| |
| \end{definitions} |
| |
| \end{document} |
| |
| |