mirror of
https://github.com/python/cpython.git
synced 2024-12-01 11:15:56 +01:00
dd15f6c315
svn+ssh://pythondev@svn.python.org/python/trunk ........ r61239 | andrew.kuchling | 2008-03-05 01:44:41 +0100 (Wed, 05 Mar 2008) | 1 line Add more items; add fragmentary notes ........ r61240 | amaury.forgeotdarc | 2008-03-05 02:50:33 +0100 (Wed, 05 Mar 2008) | 13 lines Issue#2238: some syntax errors from *args or **kwargs expressions would give bogus error messages, because of untested exceptions:: >>> f(**g(1=2)) XXX undetected error Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: 'int' object is not iterable instead of the expected SyntaxError: keyword can't be an expression Will backport. ........ r61241 | neal.norwitz | 2008-03-05 06:10:48 +0100 (Wed, 05 Mar 2008) | 3 lines Remove the files/dirs after closing the DB so the tests work on Windows. Patch from Trent Nelson. Also simplified removing a file by using test_support. ........ r61242 | neal.norwitz | 2008-03-05 06:14:18 +0100 (Wed, 05 Mar 2008) | 3 lines Get this test to pass even when there is no sound card in the system. Patch from Trent Nelson. (I can't test this.) ........ r61243 | neal.norwitz | 2008-03-05 06:20:44 +0100 (Wed, 05 Mar 2008) | 3 lines Catch OSError when trying to remove a file in case removal fails. This should prevent a failure in tearDown masking any real test failure. ........ r61244 | neal.norwitz | 2008-03-05 06:38:06 +0100 (Wed, 05 Mar 2008) | 5 lines Make the timeout longer to give slow machines a chance to pass the test before timing out. This doesn't change the duration of the test under normal circumstances. This is targetted at fixing the spurious failures on the FreeBSD buildbot primarily. ........ r61245 | neal.norwitz | 2008-03-05 06:49:03 +0100 (Wed, 05 Mar 2008) | 1 line Tabs -> spaces ........ r61246 | neal.norwitz | 2008-03-05 06:50:20 +0100 (Wed, 05 Mar 2008) | 1 line Use -u urlfetch to run more tests ........ r61247 | neal.norwitz | 2008-03-05 06:51:20 +0100 (Wed, 05 Mar 2008) | 1 line test_smtplib sometimes reports leaks too, suppress it ........ r61248 | jeffrey.yasskin | 2008-03-05 07:19:56 +0100 (Wed, 05 Mar 2008) | 5 lines Fix test_socketserver on Windows after r61099 added several signal.alarm() calls (which don't exist on non-Unix platforms). Thanks to Trent Nelson for the report and patch. ........ r61249 | georg.brandl | 2008-03-05 08:10:35 +0100 (Wed, 05 Mar 2008) | 2 lines Fix some rst. ........ r61252 | thomas.heller | 2008-03-05 15:53:39 +0100 (Wed, 05 Mar 2008) | 2 lines News entry for yesterdays commit. ........ r61253 | thomas.heller | 2008-03-05 16:34:29 +0100 (Wed, 05 Mar 2008) | 3 lines Issue 1872: Changed the struct module typecode from 't' to '?', for compatibility with PEP3118. ........ r61254 | skip.montanaro | 2008-03-05 17:41:09 +0100 (Wed, 05 Mar 2008) | 4 lines Elaborate on the role of the altinstall target when installing multiple versions. ........ r61255 | georg.brandl | 2008-03-05 20:31:44 +0100 (Wed, 05 Mar 2008) | 2 lines #2239: PYTHONPATH delimiter is os.pathsep. ........ r61256 | raymond.hettinger | 2008-03-05 21:59:58 +0100 (Wed, 05 Mar 2008) | 1 line C implementation of itertools.permutations(). ........ r61257 | raymond.hettinger | 2008-03-05 22:04:32 +0100 (Wed, 05 Mar 2008) | 1 line Small code cleanup. ........ r61260 | martin.v.loewis | 2008-03-05 23:24:31 +0100 (Wed, 05 Mar 2008) | 2 lines cd PCbuild only after deleting all pyc files. ........ r61261 | raymond.hettinger | 2008-03-06 02:15:52 +0100 (Thu, 06 Mar 2008) | 1 line Add examples. ........ r61262 | andrew.kuchling | 2008-03-06 02:36:27 +0100 (Thu, 06 Mar 2008) | 1 line Add two items ........ r61263 | georg.brandl | 2008-03-06 07:47:18 +0100 (Thu, 06 Mar 2008) | 2 lines #1725737: ignore other VC directories other than CVS and SVN's too. ........ r61264 | martin.v.loewis | 2008-03-06 07:55:22 +0100 (Thu, 06 Mar 2008) | 4 lines Patch #2232: os.tmpfile might fail on Windows if the user has no permission to create files in the root directory. Will backport to 2.5. ........ r61269 | georg.brandl | 2008-03-06 08:19:15 +0100 (Thu, 06 Mar 2008) | 2 lines Expand on re.split behavior with captured expressions. ........ r61270 | georg.brandl | 2008-03-06 08:22:09 +0100 (Thu, 06 Mar 2008) | 2 lines Little clarification of assignments. ........ r61271 | georg.brandl | 2008-03-06 08:31:34 +0100 (Thu, 06 Mar 2008) | 2 lines Add isinstance/issubclass to tutorial. ........ r61272 | georg.brandl | 2008-03-06 08:34:52 +0100 (Thu, 06 Mar 2008) | 2 lines Add missing NEWS entry for r61263. ........ r61273 | georg.brandl | 2008-03-06 08:41:16 +0100 (Thu, 06 Mar 2008) | 2 lines #2225: return nonzero status code from py_compile if not all files could be compiled. ........ r61274 | georg.brandl | 2008-03-06 08:43:02 +0100 (Thu, 06 Mar 2008) | 2 lines #2220: handle matching failure more gracefully. ........ r61275 | georg.brandl | 2008-03-06 08:45:52 +0100 (Thu, 06 Mar 2008) | 2 lines Bug #2220: handle rlcompleter attribute match failure more gracefully. ........ r61278 | martin.v.loewis | 2008-03-06 14:49:47 +0100 (Thu, 06 Mar 2008) | 1 line Rely on x64 platform configuration when building _bsddb on AMD64. ........ r61279 | martin.v.loewis | 2008-03-06 14:50:28 +0100 (Thu, 06 Mar 2008) | 1 line Update db-4.4.20 build procedure. ........ r61285 | raymond.hettinger | 2008-03-06 21:52:01 +0100 (Thu, 06 Mar 2008) | 1 line More tests. ........ r61286 | raymond.hettinger | 2008-03-06 23:51:36 +0100 (Thu, 06 Mar 2008) | 1 line Issue 2246: itertools grouper object did not participate in GC (should be backported). ........ r61288 | raymond.hettinger | 2008-03-07 02:33:20 +0100 (Fri, 07 Mar 2008) | 1 line Tweak recipes and tests ........ r61289 | jeffrey.yasskin | 2008-03-07 07:22:15 +0100 (Fri, 07 Mar 2008) | 5 lines Progress on issue #1193577 by adding a polling .shutdown() method to SocketServers. The core of the patch was written by Pedro Werneck, but any bugs are mine. I've also rearranged the code for timeouts in order to avoid interfering with the shutdown poll. ........ r61290 | nick.coghlan | 2008-03-07 15:13:28 +0100 (Fri, 07 Mar 2008) | 1 line Speed up with statements by storing the __exit__ method on the stack instead of in a temp variable (bumps the magic number for pyc files) ........ r61298 | andrew.kuchling | 2008-03-07 22:09:23 +0100 (Fri, 07 Mar 2008) | 1 line Grammar fix ........ r61303 | georg.brandl | 2008-03-08 10:54:06 +0100 (Sat, 08 Mar 2008) | 2 lines #2253: fix continue vs. finally docs. ........ r61304 | marc-andre.lemburg | 2008-03-08 11:01:43 +0100 (Sat, 08 Mar 2008) | 3 lines Add new name for Mandrake: Mandriva. ........ r61305 | georg.brandl | 2008-03-08 11:05:24 +0100 (Sat, 08 Mar 2008) | 2 lines #1533486: fix types in refcount intro. ........ r61312 | facundo.batista | 2008-03-08 17:50:27 +0100 (Sat, 08 Mar 2008) | 5 lines Issue 1106316. post_mortem()'s parameter, traceback, is now optional: it defaults to the traceback of the exception that is currently being handled. ........ r61313 | jeffrey.yasskin | 2008-03-08 19:26:54 +0100 (Sat, 08 Mar 2008) | 2 lines Add tests for with and finally performance to pybench. ........ r61314 | jeffrey.yasskin | 2008-03-08 21:08:21 +0100 (Sat, 08 Mar 2008) | 2 lines Fix pybench for pythons < 2.6, tested back to 2.3. ........ r61317 | jeffrey.yasskin | 2008-03-08 22:35:15 +0100 (Sat, 08 Mar 2008) | 3 lines Well that was dumb. platform.python_implementation returns a function, not a string. ........ r61329 | georg.brandl | 2008-03-09 16:11:39 +0100 (Sun, 09 Mar 2008) | 2 lines #2249: document assertTrue and assertFalse. ........ r61332 | neal.norwitz | 2008-03-09 20:03:42 +0100 (Sun, 09 Mar 2008) | 4 lines Introduce a lock to fix a race condition which caused an exception in the test. Some buildbots were consistently failing (e.g., amd64). Also remove a couple of semi-colons. ........ r61344 | raymond.hettinger | 2008-03-11 01:19:07 +0100 (Tue, 11 Mar 2008) | 1 line Add recipe to docs. ........ r61350 | guido.van.rossum | 2008-03-11 22:18:06 +0100 (Tue, 11 Mar 2008) | 3 lines Fix the overflows in expandtabs(). "This time for sure!" (Exploit at request.) ........ r61351 | raymond.hettinger | 2008-03-11 22:37:46 +0100 (Tue, 11 Mar 2008) | 1 line Improve docs for itemgetter(). Show that it works with slices. ........ r61363 | georg.brandl | 2008-03-13 08:15:56 +0100 (Thu, 13 Mar 2008) | 2 lines #2265: fix example. ........ r61364 | georg.brandl | 2008-03-13 08:17:14 +0100 (Thu, 13 Mar 2008) | 2 lines #2270: fix typo. ........ r61365 | georg.brandl | 2008-03-13 08:21:41 +0100 (Thu, 13 Mar 2008) | 2 lines #1720705: add docs about import/threading interaction, wording by Nick. ........ r61366 | andrew.kuchling | 2008-03-13 12:07:35 +0100 (Thu, 13 Mar 2008) | 1 line Add class decorators ........ r61367 | raymond.hettinger | 2008-03-13 17:43:17 +0100 (Thu, 13 Mar 2008) | 1 line Add 2-to-3 support for the itertools moved to builtins or renamed. ........ r61368 | raymond.hettinger | 2008-03-13 17:43:59 +0100 (Thu, 13 Mar 2008) | 1 line Consistent tense. ........ r61369 | raymond.hettinger | 2008-03-13 20:03:51 +0100 (Thu, 13 Mar 2008) | 1 line Issue 2274: Add heapq.heappushpop(). ........ r61370 | raymond.hettinger | 2008-03-13 20:33:34 +0100 (Thu, 13 Mar 2008) | 1 line Simplify the nlargest() code using heappushpop(). ........ r61371 | brett.cannon | 2008-03-13 21:27:00 +0100 (Thu, 13 Mar 2008) | 4 lines Move test_thread over to unittest. Commits GHOP 237. Thanks Benjamin Peterson for the patch. ........ r61372 | brett.cannon | 2008-03-13 21:33:10 +0100 (Thu, 13 Mar 2008) | 4 lines Move test_tokenize to doctest. Done as GHOP 238 by Josip Dzolonga. ........ r61373 | brett.cannon | 2008-03-13 21:47:41 +0100 (Thu, 13 Mar 2008) | 4 lines Convert test_contains, test_crypt, and test_select to unittest. Patch from GHOP 294 by David Marek. ........ r61374 | brett.cannon | 2008-03-13 22:02:16 +0100 (Thu, 13 Mar 2008) | 4 lines Move test_gdbm to use unittest. Closes issue #1960. Thanks Giampaolo Rodola. ........ r61375 | brett.cannon | 2008-03-13 22:09:28 +0100 (Thu, 13 Mar 2008) | 4 lines Convert test_fcntl to unittest. Closes issue #2055. Thanks Giampaolo Rodola. ........ r61376 | raymond.hettinger | 2008-03-14 06:03:44 +0100 (Fri, 14 Mar 2008) | 1 line Leave heapreplace() unchanged. ........ r61378 | martin.v.loewis | 2008-03-14 14:56:09 +0100 (Fri, 14 Mar 2008) | 2 lines Patch #2284: add -x64 option to rt.bat. ........ r61379 | martin.v.loewis | 2008-03-14 14:57:59 +0100 (Fri, 14 Mar 2008) | 2 lines Use -x64 flag. ........ r61382 | brett.cannon | 2008-03-14 15:03:10 +0100 (Fri, 14 Mar 2008) | 2 lines Remove a bad test. ........ r61383 | mark.dickinson | 2008-03-14 15:23:37 +0100 (Fri, 14 Mar 2008) | 9 lines Issue 705836: Fix struct.pack(">f", 1e40) to behave consistently across platforms: it should now raise OverflowError on all platforms. (Previously it raised OverflowError only on non IEEE 754 platforms.) Also fix the (already existing) test for this behaviour so that it actually raises TestFailed instead of just referencing it. ........ r61387 | thomas.heller | 2008-03-14 22:06:21 +0100 (Fri, 14 Mar 2008) | 1 line Remove unneeded initializer. ........ r61388 | martin.v.loewis | 2008-03-14 22:19:28 +0100 (Fri, 14 Mar 2008) | 2 lines Run debug version, cd to PCbuild. ........ r61392 | georg.brandl | 2008-03-15 00:10:34 +0100 (Sat, 15 Mar 2008) | 2 lines Remove obsolete paragraph. #2288. ........ r61395 | georg.brandl | 2008-03-15 01:20:19 +0100 (Sat, 15 Mar 2008) | 2 lines Fix lots of broken links in the docs, found by Sphinx' external link checker. ........ r61396 | skip.montanaro | 2008-03-15 03:32:49 +0100 (Sat, 15 Mar 2008) | 1 line note that fork and forkpty raise OSError on failure ........ r61402 | skip.montanaro | 2008-03-15 17:04:45 +0100 (Sat, 15 Mar 2008) | 1 line add %f format to datetime - issue 1158 ........ r61403 | skip.montanaro | 2008-03-15 17:07:11 +0100 (Sat, 15 Mar 2008) | 2 lines . ........
357 lines
18 KiB
ReStructuredText
357 lines
18 KiB
ReStructuredText
*************************
|
|
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 the :file:`Misc/COPYRIGHT` file in the
|
|
source distribution, or the section :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://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.
|
|
|
|
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.
|
|
|