Andrew M. Kuchling | e8f44d6 | 2005-08-30 01:25:05 +0000 | [diff] [blame] | 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 | |
Andrew M. Kuchling | 8230df3 | 2005-08-31 14:43:10 +0000 | [diff] [blame] | 184 | (From \url{http://www.catb.org/~esr/jargon/html/C/compact.html}) |
Andrew M. Kuchling | e8f44d6 | 2005-08-30 01:25:05 +0000 | [diff] [blame] | 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 | |
Andrew M. Kuchling | 8230df3 | 2005-08-31 14:43:10 +0000 | [diff] [blame] | 288 | See \url{http://wiki.python.org/moin/OrganizationsUsingPython} for a list of some of the |
Andrew M. Kuchling | e8f44d6 | 2005-08-30 01:25:05 +0000 | [diff] [blame] | 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 | |
Andrew M. Kuchling | e8f44d6 | 2005-08-30 01:25:05 +0000 | [diff] [blame] | 335 | |
Andrew M. Kuchling | 8230df3 | 2005-08-31 14:43:10 +0000 | [diff] [blame] | 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. |
Andrew M. Kuchling | e8f44d6 | 2005-08-30 01:25:05 +0000 | [diff] [blame] | 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 | |
Andrew M. Kuchling | 8230df3 | 2005-08-31 14:43:10 +0000 | [diff] [blame] | 373 | \term{\url{http://pythonjournal.cognizor.com/pyj1/Everitt-Feit_interview98-V1.html}} |
Andrew M. Kuchling | e8f44d6 | 2005-08-30 01:25:05 +0000 | [diff] [blame] | 374 | |
Andrew M. Kuchling | 8230df3 | 2005-08-31 14:43:10 +0000 | [diff] [blame] | 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. |
Andrew M. Kuchling | e8f44d6 | 2005-08-30 01:25:05 +0000 | [diff] [blame] | 378 | |
Andrew M. Kuchling | 8230df3 | 2005-08-31 14:43:10 +0000 | [diff] [blame] | 379 | %\term{\url{http://www.python.org/psa/Commercial.html}} |
Andrew M. Kuchling | e8f44d6 | 2005-08-30 01:25:05 +0000 | [diff] [blame] | 380 | |
Andrew M. Kuchling | 8230df3 | 2005-08-31 14:43:10 +0000 | [diff] [blame] | 381 | %Robin Friedrich wrote this document on how to support Python's use in |
| 382 | %commercial projects. |
Andrew M. Kuchling | e8f44d6 | 2005-08-30 01:25:05 +0000 | [diff] [blame] | 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 | |