1 |
|
---|
2 | \documentclass{howto}
|
---|
3 |
|
---|
4 | \title{Python Advocacy HOWTO}
|
---|
5 |
|
---|
6 | \release{0.03}
|
---|
7 |
|
---|
8 | \author{A.M. Kuchling}
|
---|
9 | \authoraddress{\email{amk@amk.ca}}
|
---|
10 |
|
---|
11 | \begin{document}
|
---|
12 | \maketitle
|
---|
13 |
|
---|
14 | \begin{abstract}
|
---|
15 | \noindent
|
---|
16 | It's usually difficult to get your management to accept open source
|
---|
17 | software, and Python is no exception to this rule. This document
|
---|
18 | discusses reasons to use Python, strategies for winning acceptance,
|
---|
19 | facts and arguments you can use, and cases where you \emph{shouldn't}
|
---|
20 | try to use Python.
|
---|
21 |
|
---|
22 | This document is available from the Python HOWTO page at
|
---|
23 | \url{http://www.python.org/doc/howto}.
|
---|
24 |
|
---|
25 | \end{abstract}
|
---|
26 |
|
---|
27 | \tableofcontents
|
---|
28 |
|
---|
29 | \section{Reasons to Use Python}
|
---|
30 |
|
---|
31 | There are several reasons to incorporate a scripting language into
|
---|
32 | your development process, and this section will discuss them, and why
|
---|
33 | Python has some properties that make it a particularly good choice.
|
---|
34 |
|
---|
35 | \subsection{Programmability}
|
---|
36 |
|
---|
37 | Programs are often organized in a modular fashion. Lower-level
|
---|
38 | operations are grouped together, and called by higher-level functions,
|
---|
39 | which may in turn be used as basic operations by still further upper
|
---|
40 | levels.
|
---|
41 |
|
---|
42 | For example, the lowest level might define a very low-level
|
---|
43 | set of functions for accessing a hash table. The next level might use
|
---|
44 | hash tables to store the headers of a mail message, mapping a header
|
---|
45 | name like \samp{Date} to a value such as \samp{Tue, 13 May 1997
|
---|
46 | 20:00:54 -0400}. A yet higher level may operate on message objects,
|
---|
47 | without knowing or caring that message headers are stored in a hash
|
---|
48 | table, and so forth.
|
---|
49 |
|
---|
50 | Often, the lowest levels do very simple things; they implement a data
|
---|
51 | structure such as a binary tree or hash table, or they perform some
|
---|
52 | simple computation, such as converting a date string to a number. The
|
---|
53 | higher levels then contain logic connecting these primitive
|
---|
54 | operations. Using the approach, the primitives can be seen as basic
|
---|
55 | building blocks which are then glued together to produce the complete
|
---|
56 | product.
|
---|
57 |
|
---|
58 | Why is this design approach relevant to Python? Because Python is
|
---|
59 | well suited to functioning as such a glue language. A common approach
|
---|
60 | is to write a Python module that implements the lower level
|
---|
61 | operations; for the sake of speed, the implementation might be in C,
|
---|
62 | Java, or even Fortran. Once the primitives are available to Python
|
---|
63 | programs, the logic underlying higher level operations is written in
|
---|
64 | the form of Python code. The high-level logic is then more
|
---|
65 | understandable, and easier to modify.
|
---|
66 |
|
---|
67 | John Ousterhout wrote a paper that explains this idea at greater
|
---|
68 | length, entitled ``Scripting: Higher Level Programming for the 21st
|
---|
69 | Century''. I recommend that you read this paper; see the references
|
---|
70 | for the URL. Ousterhout is the inventor of the Tcl language, and
|
---|
71 | therefore argues that Tcl should be used for this purpose; he only
|
---|
72 | briefly refers to other languages such as Python, Perl, and
|
---|
73 | Lisp/Scheme, but in reality, Ousterhout's argument applies to
|
---|
74 | scripting languages in general, since you could equally write
|
---|
75 | extensions for any of the languages mentioned above.
|
---|
76 |
|
---|
77 | \subsection{Prototyping}
|
---|
78 |
|
---|
79 | In \emph{The Mythical Man-Month}, Fredrick Brooks suggests the
|
---|
80 | following rule when planning software projects: ``Plan to throw one
|
---|
81 | away; you will anyway.'' Brooks is saying that the first attempt at a
|
---|
82 | software design often turns out to be wrong; unless the problem is
|
---|
83 | very simple or you're an extremely good designer, you'll find that new
|
---|
84 | requirements and features become apparent once development has
|
---|
85 | actually started. If these new requirements can't be cleanly
|
---|
86 | incorporated into the program's structure, you're presented with two
|
---|
87 | unpleasant choices: hammer the new features into the program somehow,
|
---|
88 | or scrap everything and write a new version of the program, taking the
|
---|
89 | new features into account from the beginning.
|
---|
90 |
|
---|
91 | Python provides you with a good environment for quickly developing an
|
---|
92 | initial prototype. That lets you get the overall program structure
|
---|
93 | and logic right, and you can fine-tune small details in the fast
|
---|
94 | development cycle that Python provides. Once you're satisfied with
|
---|
95 | the GUI interface or program output, you can translate the Python code
|
---|
96 | into C++, Fortran, Java, or some other compiled language.
|
---|
97 |
|
---|
98 | Prototyping means you have to be careful not to use too many Python
|
---|
99 | features that are hard to implement in your other language. Using
|
---|
100 | \code{eval()}, or regular expressions, or the \module{pickle} module,
|
---|
101 | means that you're going to need C or Java libraries for formula
|
---|
102 | evaluation, regular expressions, and serialization, for example. But
|
---|
103 | it's not hard to avoid such tricky code, and in the end the
|
---|
104 | translation usually isn't very difficult. The resulting code can be
|
---|
105 | rapidly debugged, because any serious logical errors will have been
|
---|
106 | removed from the prototype, leaving only more minor slip-ups in the
|
---|
107 | translation to track down.
|
---|
108 |
|
---|
109 | This strategy builds on the earlier discussion of programmability.
|
---|
110 | Using Python as glue to connect lower-level components has obvious
|
---|
111 | relevance for constructing prototype systems. In this way Python can
|
---|
112 | help you with development, even if end users never come in contact
|
---|
113 | with Python code at all. If the performance of the Python version is
|
---|
114 | adequate and corporate politics allow it, you may not need to do a
|
---|
115 | translation into C or Java, but it can still be faster to develop a
|
---|
116 | prototype and then translate it, instead of attempting to produce the
|
---|
117 | final version immediately.
|
---|
118 |
|
---|
119 | One example of this development strategy is Microsoft Merchant Server.
|
---|
120 | Version 1.0 was written in pure Python, by a company that subsequently
|
---|
121 | was purchased by Microsoft. Version 2.0 began to translate the code
|
---|
122 | into \Cpp, shipping with some \Cpp code and some Python code. Version
|
---|
123 | 3.0 didn't contain any Python at all; all the code had been translated
|
---|
124 | into \Cpp. Even though the product doesn't contain a Python
|
---|
125 | interpreter, the Python language has still served a useful purpose by
|
---|
126 | speeding up development.
|
---|
127 |
|
---|
128 | This is a very common use for Python. Past conference papers have
|
---|
129 | also described this approach for developing high-level numerical
|
---|
130 | algorithms; see David M. Beazley and Peter S. Lomdahl's paper
|
---|
131 | ``Feeding a Large-scale Physics Application to Python'' in the
|
---|
132 | references for a good example. If an algorithm's basic operations are
|
---|
133 | things like "Take the inverse of this 4000x4000 matrix", and are
|
---|
134 | implemented in some lower-level language, then Python has almost no
|
---|
135 | additional performance cost; the extra time required for Python to
|
---|
136 | evaluate an expression like \code{m.invert()} is dwarfed by the cost
|
---|
137 | of the actual computation. It's particularly good for applications
|
---|
138 | where seemingly endless tweaking is required to get things right. GUI
|
---|
139 | interfaces and Web sites are prime examples.
|
---|
140 |
|
---|
141 | The Python code is also shorter and faster to write (once you're
|
---|
142 | familiar with Python), so it's easier to throw it away if you decide
|
---|
143 | your approach was wrong; if you'd spent two weeks working on it
|
---|
144 | instead of just two hours, you might waste time trying to patch up
|
---|
145 | what you've got out of a natural reluctance to admit that those two
|
---|
146 | weeks were wasted. Truthfully, those two weeks haven't been wasted,
|
---|
147 | since you've learnt something about the problem and the technology
|
---|
148 | you're using to solve it, but it's human nature to view this as a
|
---|
149 | failure of some sort.
|
---|
150 |
|
---|
151 | \subsection{Simplicity and Ease of Understanding}
|
---|
152 |
|
---|
153 | Python is definitely \emph{not} a toy language that's only usable for
|
---|
154 | small tasks. The language features are general and powerful enough to
|
---|
155 | enable it to be used for many different purposes. It's useful at the
|
---|
156 | small end, for 10- or 20-line scripts, but it also scales up to larger
|
---|
157 | systems that contain thousands of lines of code.
|
---|
158 |
|
---|
159 | However, this expressiveness doesn't come at the cost of an obscure or
|
---|
160 | tricky syntax. While Python has some dark corners that can lead to
|
---|
161 | obscure code, there are relatively few such corners, and proper design
|
---|
162 | can isolate their use to only a few classes or modules. It's
|
---|
163 | certainly possible to write confusing code by using too many features
|
---|
164 | with too little concern for clarity, but most Python code can look a
|
---|
165 | lot like a slightly-formalized version of human-understandable
|
---|
166 | pseudocode.
|
---|
167 |
|
---|
168 | In \emph{The New Hacker's Dictionary}, Eric S. Raymond gives the following
|
---|
169 | definition for "compact":
|
---|
170 |
|
---|
171 | \begin{quotation}
|
---|
172 | Compact \emph{adj.} Of a design, describes the valuable property
|
---|
173 | that it can all be apprehended at once in one's head. This
|
---|
174 | generally means the thing created from the design can be used
|
---|
175 | with greater facility and fewer errors than an equivalent tool
|
---|
176 | that is not compact. Compactness does not imply triviality or
|
---|
177 | lack of power; for example, C is compact and FORTRAN is not,
|
---|
178 | but C is more powerful than FORTRAN. Designs become
|
---|
179 | non-compact through accreting features and cruft that don't
|
---|
180 | merge cleanly into the overall design scheme (thus, some fans
|
---|
181 | of Classic C maintain that ANSI C is no longer compact).
|
---|
182 | \end{quotation}
|
---|
183 |
|
---|
184 | (From \url{http://www.catb.org/~esr/jargon/html/C/compact.html})
|
---|
185 |
|
---|
186 | In this sense of the word, Python is quite compact, because the
|
---|
187 | language has just a few ideas, which are used in lots of places. Take
|
---|
188 | namespaces, for example. Import a module with \code{import math}, and
|
---|
189 | you create a new namespace called \samp{math}. Classes are also
|
---|
190 | namespaces that share many of the properties of modules, and have a
|
---|
191 | few of their own; for example, you can create instances of a class.
|
---|
192 | Instances? They're yet another namespace. Namespaces are currently
|
---|
193 | implemented as Python dictionaries, so they have the same methods as
|
---|
194 | the standard dictionary data type: .keys() returns all the keys, and
|
---|
195 | so forth.
|
---|
196 |
|
---|
197 | This simplicity arises from Python's development history. The
|
---|
198 | language syntax derives from different sources; ABC, a relatively
|
---|
199 | obscure teaching language, is one primary influence, and Modula-3 is
|
---|
200 | another. (For more information about ABC and Modula-3, consult their
|
---|
201 | respective Web sites at \url{http://www.cwi.nl/~steven/abc/} and
|
---|
202 | \url{http://www.m3.org}.) Other features have come from C, Icon,
|
---|
203 | Algol-68, and even Perl. Python hasn't really innovated very much,
|
---|
204 | but instead has tried to keep the language small and easy to learn,
|
---|
205 | building on ideas that have been tried in other languages and found
|
---|
206 | useful.
|
---|
207 |
|
---|
208 | Simplicity is a virtue that should not be underestimated. It lets you
|
---|
209 | learn the language more quickly, and then rapidly write code, code
|
---|
210 | that often works the first time you run it.
|
---|
211 |
|
---|
212 | \subsection{Java Integration}
|
---|
213 |
|
---|
214 | If you're working with Java, Jython
|
---|
215 | (\url{http://www.jython.org/}) is definitely worth your
|
---|
216 | attention. Jython is a re-implementation of Python in Java that
|
---|
217 | compiles Python code into Java bytecodes. The resulting environment
|
---|
218 | has very tight, almost seamless, integration with Java. It's trivial
|
---|
219 | to access Java classes from Python, and you can write Python classes
|
---|
220 | that subclass Java classes. Jython can be used for prototyping Java
|
---|
221 | applications in much the same way CPython is used, and it can also be
|
---|
222 | used for test suites for Java code, or embedded in a Java application
|
---|
223 | to add scripting capabilities.
|
---|
224 |
|
---|
225 | \section{Arguments and Rebuttals}
|
---|
226 |
|
---|
227 | Let's say that you've decided upon Python as the best choice for your
|
---|
228 | application. How can you convince your management, or your fellow
|
---|
229 | developers, to use Python? This section lists some common arguments
|
---|
230 | against using Python, and provides some possible rebuttals.
|
---|
231 |
|
---|
232 | \emph{Python is freely available software that doesn't cost anything.
|
---|
233 | How good can it be?}
|
---|
234 |
|
---|
235 | Very good, indeed. These days Linux and Apache, two other pieces of
|
---|
236 | open source software, are becoming more respected as alternatives to
|
---|
237 | commercial software, but Python hasn't had all the publicity.
|
---|
238 |
|
---|
239 | Python has been around for several years, with many users and
|
---|
240 | developers. Accordingly, the interpreter has been used by many
|
---|
241 | people, and has gotten most of the bugs shaken out of it. While bugs
|
---|
242 | are still discovered at intervals, they're usually either quite
|
---|
243 | obscure (they'd have to be, for no one to have run into them before)
|
---|
244 | or they involve interfaces to external libraries. The internals of
|
---|
245 | the language itself are quite stable.
|
---|
246 |
|
---|
247 | Having the source code should be viewed as making the software
|
---|
248 | available for peer review; people can examine the code, suggest (and
|
---|
249 | implement) improvements, and track down bugs. To find out more about
|
---|
250 | the idea of open source code, along with arguments and case studies
|
---|
251 | supporting it, go to \url{http://www.opensource.org}.
|
---|
252 |
|
---|
253 | \emph{Who's going to support it?}
|
---|
254 |
|
---|
255 | Python has a sizable community of developers, and the number is still
|
---|
256 | growing. The Internet community surrounding the language is an active
|
---|
257 | one, and is worth being considered another one of Python's advantages.
|
---|
258 | Most questions posted to the comp.lang.python newsgroup are quickly
|
---|
259 | answered by someone.
|
---|
260 |
|
---|
261 | Should you need to dig into the source code, you'll find it's clear
|
---|
262 | and well-organized, so it's not very difficult to write extensions and
|
---|
263 | track down bugs yourself. If you'd prefer to pay for support, there
|
---|
264 | are companies and individuals who offer commercial support for Python.
|
---|
265 |
|
---|
266 | \emph{Who uses Python for serious work?}
|
---|
267 |
|
---|
268 | Lots of people; one interesting thing about Python is the surprising
|
---|
269 | diversity of applications that it's been used for. People are using
|
---|
270 | Python to:
|
---|
271 |
|
---|
272 | \begin{itemize}
|
---|
273 | \item Run Web sites
|
---|
274 | \item Write GUI interfaces
|
---|
275 | \item Control
|
---|
276 | number-crunching code on supercomputers
|
---|
277 | \item Make a commercial application scriptable by embedding the Python
|
---|
278 | interpreter inside it
|
---|
279 | \item Process large XML data sets
|
---|
280 | \item Build test suites for C or Java code
|
---|
281 | \end{itemize}
|
---|
282 |
|
---|
283 | Whatever your application domain is, there's probably someone who's
|
---|
284 | used Python for something similar. Yet, despite being useable for
|
---|
285 | such high-end applications, Python's still simple enough to use for
|
---|
286 | little jobs.
|
---|
287 |
|
---|
288 | See \url{http://wiki.python.org/moin/OrganizationsUsingPython} for a list of some of the
|
---|
289 | organizations that use Python.
|
---|
290 |
|
---|
291 | \emph{What are the restrictions on Python's use?}
|
---|
292 |
|
---|
293 | They're practically nonexistent. Consult the \file{Misc/COPYRIGHT}
|
---|
294 | file in the source distribution, or
|
---|
295 | \url{http://www.python.org/doc/Copyright.html} for the full language,
|
---|
296 | but it boils down to three conditions.
|
---|
297 |
|
---|
298 | \begin{itemize}
|
---|
299 |
|
---|
300 | \item You have to leave the copyright notice on the software; if you
|
---|
301 | don't include the source code in a product, you have to put the
|
---|
302 | copyright notice in the supporting documentation.
|
---|
303 |
|
---|
304 | \item Don't claim that the institutions that have developed Python
|
---|
305 | endorse your product in any way.
|
---|
306 |
|
---|
307 | \item If something goes wrong, you can't sue for damages. Practically
|
---|
308 | all software licences contain this condition.
|
---|
309 |
|
---|
310 | \end{itemize}
|
---|
311 |
|
---|
312 | Notice that you don't have to provide source code for anything that
|
---|
313 | contains Python or is built with it. Also, the Python interpreter and
|
---|
314 | accompanying documentation can be modified and redistributed in any
|
---|
315 | way you like, and you don't have to pay anyone any licensing fees at
|
---|
316 | all.
|
---|
317 |
|
---|
318 | \emph{Why should we use an obscure language like Python instead of
|
---|
319 | well-known language X?}
|
---|
320 |
|
---|
321 | I hope this HOWTO, and the documents listed in the final section, will
|
---|
322 | help convince you that Python isn't obscure, and has a healthily
|
---|
323 | growing user base. One word of advice: always present Python's
|
---|
324 | positive advantages, instead of concentrating on language X's
|
---|
325 | failings. People want to know why a solution is good, rather than why
|
---|
326 | all the other solutions are bad. So instead of attacking a competing
|
---|
327 | solution on various grounds, simply show how Python's virtues can
|
---|
328 | help.
|
---|
329 |
|
---|
330 |
|
---|
331 | \section{Useful Resources}
|
---|
332 |
|
---|
333 | \begin{definitions}
|
---|
334 |
|
---|
335 |
|
---|
336 | \term{\url{http://www.pythonology.com/success}}
|
---|
337 |
|
---|
338 | The Python Success Stories are a collection of stories from successful
|
---|
339 | users of Python, with the emphasis on business and corporate users.
|
---|
340 |
|
---|
341 | %\term{\url{http://www.fsbassociates.com/books/pythonchpt1.htm}}
|
---|
342 |
|
---|
343 | %The first chapter of \emph{Internet Programming with Python} also
|
---|
344 | %examines some of the reasons for using Python. The book is well worth
|
---|
345 | %buying, but the publishers have made the first chapter available on
|
---|
346 | %the Web.
|
---|
347 |
|
---|
348 | \term{\url{http://home.pacbell.net/ouster/scripting.html}}
|
---|
349 |
|
---|
350 | John Ousterhout's white paper on scripting is a good argument for the
|
---|
351 | utility of scripting languages, though naturally enough, he emphasizes
|
---|
352 | Tcl, the language he developed. Most of the arguments would apply to
|
---|
353 | any scripting language.
|
---|
354 |
|
---|
355 | \term{\url{http://www.python.org/workshops/1997-10/proceedings/beazley.html}}
|
---|
356 |
|
---|
357 | The authors, David M. Beazley and Peter S. Lomdahl,
|
---|
358 | describe their use of Python at Los Alamos National Laboratory.
|
---|
359 | It's another good example of how Python can help get real work done.
|
---|
360 | This quotation from the paper has been echoed by many people:
|
---|
361 |
|
---|
362 | \begin{quotation}
|
---|
363 | Originally developed as a large monolithic application for
|
---|
364 | massively parallel processing systems, we have used Python to
|
---|
365 | transform our application into a flexible, highly modular, and
|
---|
366 | extremely powerful system for performing simulation, data
|
---|
367 | analysis, and visualization. In addition, we describe how Python
|
---|
368 | has solved a number of important problems related to the
|
---|
369 | development, debugging, deployment, and maintenance of scientific
|
---|
370 | software.
|
---|
371 | \end{quotation}
|
---|
372 |
|
---|
373 | \term{\url{http://pythonjournal.cognizor.com/pyj1/Everitt-Feit_interview98-V1.html}}
|
---|
374 |
|
---|
375 | This interview with Andy Feit, discussing Infoseek's use of Python, can be
|
---|
376 | used to show that choosing Python didn't introduce any difficulties
|
---|
377 | into a company's development process, and provided some substantial benefits.
|
---|
378 |
|
---|
379 | %\term{\url{http://www.python.org/psa/Commercial.html}}
|
---|
380 |
|
---|
381 | %Robin Friedrich wrote this document on how to support Python's use in
|
---|
382 | %commercial projects.
|
---|
383 |
|
---|
384 | \term{\url{http://www.python.org/workshops/1997-10/proceedings/stein.ps}}
|
---|
385 |
|
---|
386 | For the 6th Python conference, Greg Stein presented a paper that
|
---|
387 | traced Python's adoption and usage at a startup called eShop, and
|
---|
388 | later at Microsoft.
|
---|
389 |
|
---|
390 | \term{\url{http://www.opensource.org}}
|
---|
391 |
|
---|
392 | Management may be doubtful of the reliability and usefulness of
|
---|
393 | software that wasn't written commercially. This site presents
|
---|
394 | arguments that show how open source software can have considerable
|
---|
395 | advantages over closed-source software.
|
---|
396 |
|
---|
397 | \term{\url{http://sunsite.unc.edu/LDP/HOWTO/mini/Advocacy.html}}
|
---|
398 |
|
---|
399 | The Linux Advocacy mini-HOWTO was the inspiration for this document,
|
---|
400 | and is also well worth reading for general suggestions on winning
|
---|
401 | acceptance for a new technology, such as Linux or Python. In general,
|
---|
402 | you won't make much progress by simply attacking existing systems and
|
---|
403 | complaining about their inadequacies; this often ends up looking like
|
---|
404 | unfocused whining. It's much better to point out some of the many
|
---|
405 | areas where Python is an improvement over other systems.
|
---|
406 |
|
---|
407 | \end{definitions}
|
---|
408 |
|
---|
409 | \end{document}
|
---|
410 |
|
---|
411 |
|
---|