mirror of
				https://github.com/python/cpython.git
				synced 2025-11-03 19:34:08 +00:00 
			
		
		
		
	#17729: merge with 3.3.
This commit is contained in:
		
						commit
						99b3caf514
					
				
					 1 changed files with 0 additions and 355 deletions
				
			
		| 
						 | 
				
			
			@ -1,355 +0,0 @@
 | 
			
		|||
*************************
 | 
			
		||||
  Python Advocacy HOWTO
 | 
			
		||||
*************************
 | 
			
		||||
 | 
			
		||||
:Author: A.M. Kuchling
 | 
			
		||||
:Release: 0.03
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
.. topic:: Abstract
 | 
			
		||||
 | 
			
		||||
   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 *shouldn't* try to use Python.
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
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.
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
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 ``Date`` to a value such
 | 
			
		||||
as ``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.
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
Prototyping
 | 
			
		||||
-----------
 | 
			
		||||
 | 
			
		||||
In *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 ``eval()``, or regular
 | 
			
		||||
expressions, or the :mod:`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 C++, shipping with some
 | 
			
		||||
C++code and some Python code.  Version 3.0 didn't contain any Python at all; all
 | 
			
		||||
the code had been translated into C++.  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 ``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.
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
Simplicity and Ease of Understanding
 | 
			
		||||
------------------------------------
 | 
			
		||||
 | 
			
		||||
Python is definitely *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 *The New Hacker's Dictionary*, Eric S. Raymond gives the following definition
 | 
			
		||||
for "compact":
 | 
			
		||||
 | 
			
		||||
.. epigraph::
 | 
			
		||||
 | 
			
		||||
   Compact *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).
 | 
			
		||||
 | 
			
		||||
   (From 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 ``import math``, and you create a new namespace
 | 
			
		||||
called ``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 http://www.cwi.nl/~steven/abc/
 | 
			
		||||
and 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.
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
Java Integration
 | 
			
		||||
----------------
 | 
			
		||||
 | 
			
		||||
If you're working with Java, Jython (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.
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
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.
 | 
			
		||||
 | 
			
		||||
**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 http://www.opensource.org.
 | 
			
		||||
 | 
			
		||||
**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.
 | 
			
		||||
 | 
			
		||||
**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:
 | 
			
		||||
 | 
			
		||||
* Run Web sites
 | 
			
		||||
 | 
			
		||||
* Write GUI interfaces
 | 
			
		||||
 | 
			
		||||
* Control number-crunching code on supercomputers
 | 
			
		||||
 | 
			
		||||
* Make a commercial application scriptable by embedding the Python interpreter
 | 
			
		||||
  inside it
 | 
			
		||||
 | 
			
		||||
* Process large XML data sets
 | 
			
		||||
 | 
			
		||||
* Build test suites for C or Java code
 | 
			
		||||
 | 
			
		||||
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 http://wiki.python.org/moin/OrganizationsUsingPython for a list of some of
 | 
			
		||||
the  organizations that use Python.
 | 
			
		||||
 | 
			
		||||
**What are the restrictions on Python's use?**
 | 
			
		||||
 | 
			
		||||
They're practically nonexistent.  Consult :ref:`history-and-license` for the full
 | 
			
		||||
language, but it boils down to three conditions:
 | 
			
		||||
 | 
			
		||||
* 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.
 | 
			
		||||
 | 
			
		||||
* Don't claim that the institutions that have developed Python endorse your
 | 
			
		||||
  product in any way.
 | 
			
		||||
 | 
			
		||||
* If something goes wrong, you can't sue for damages.  Practically all software
 | 
			
		||||
  licenses contain this condition.
 | 
			
		||||
 | 
			
		||||
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.
 | 
			
		||||
 | 
			
		||||
**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.
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
Useful Resources
 | 
			
		||||
================
 | 
			
		||||
 | 
			
		||||
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.
 | 
			
		||||
 | 
			
		||||
.. 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.
 | 
			
		||||
 | 
			
		||||
http://www.tcl.tk/doc/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.
 | 
			
		||||
 | 
			
		||||
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:
 | 
			
		||||
 | 
			
		||||
   .. epigraph::
 | 
			
		||||
 | 
			
		||||
      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.
 | 
			
		||||
 | 
			
		||||
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.
 | 
			
		||||
 | 
			
		||||
.. http://www.python.org/psa/Commercial.html
 | 
			
		||||
   Robin Friedrich wrote this document on how to support Python's use in
 | 
			
		||||
   commercial projects.
 | 
			
		||||
 | 
			
		||||
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.
 | 
			
		||||
 | 
			
		||||
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.
 | 
			
		||||
 | 
			
		||||
http://www.faqs.org/docs/Linux-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.
 | 
			
		||||
 | 
			
		||||
		Loading…
	
	Add table
		Add a link
		
	
		Reference in a new issue