mirror of
https://github.com/python/cpython.git
synced 2024-11-24 02:15:30 +08:00
566 lines
22 KiB
Plaintext
566 lines
22 KiB
Plaintext
This is Python release 1.3
|
|
==========================
|
|
|
|
|
|
What's new in this release?
|
|
---------------------------
|
|
|
|
- Keyword parameters (see the last chapter of the tutorial).
|
|
- Third argument to raise (the stacktrace to provide).
|
|
- Faster function and method calls.
|
|
- Jim Fulton's abstract object interface (Include/abstract.h).
|
|
- Support for Tk 4.0 in Tkinter (Tkinter now supports keywords!).
|
|
- Rewritten htmllib.py (HTML parser), with new formatter.py.
|
|
- Rewritten rexec.py (restricted execution).
|
|
- New modules ni.py and ihooks.py (package support and more).
|
|
- And lots more that you'll have to discover on your own (see chapter
|
|
12 of the Tutorial).
|
|
|
|
|
|
What is Python anyway?
|
|
----------------------
|
|
|
|
Python is an interpreted object-oriented programming language, and is
|
|
often compared to Tcl, Perl or Scheme. For a quick summary of what
|
|
Python can mean for a UNIX/C programmer, read Misc/BLURB.LUTZ.
|
|
|
|
|
|
If you don't read instructions
|
|
------------------------------
|
|
|
|
Congratulations on getting this far. :-)
|
|
|
|
To start building right away (on UNIX): type "./configure" in the
|
|
current directory and when it finishes, type "make". The section
|
|
Build Instructions below is still recommended reading. :-)
|
|
|
|
|
|
Copyright issues
|
|
----------------
|
|
|
|
Python is COPYRIGHTED but free to use for all. See the full copyright
|
|
notice at the end of this file.
|
|
|
|
The Python distribution is *not* affected by the GNU Public Licence
|
|
(GPL). There are interfaces to some GNU code but these are entirely
|
|
optional and no GNU code is distributed with Python. For all these
|
|
packages, GPL-free public domain versions also exist.
|
|
|
|
|
|
A modest plug
|
|
=============
|
|
|
|
|
|
*************************************************************************
|
|
* *
|
|
* Python exists, and is free, thanks to the contributed efforts *
|
|
* of many people. The PSA was created to maximize the results *
|
|
* of those efforts, by helping to coordinate them. The PSA *
|
|
* operates web, ftp and email servers, organizes Python *
|
|
* workshops, and engages in other activities that benefit the *
|
|
* Python user community. The PSA is seeking support for these *
|
|
* activities. See this URL for information on how to join: *
|
|
* http://www.python.org/psa/Joining.html *
|
|
* *
|
|
*************************************************************************
|
|
|
|
|
|
Build instructions
|
|
==================
|
|
|
|
Before you start building Python, you must first configure it. This
|
|
entails (at least) running the script "./configure", which figures out
|
|
your system configuration and creates several Makefiles. (It takes a
|
|
minute or two -- please be patient!) When it's done, you are ready to
|
|
run make. Typing "make" in the toplevel directory will recursively
|
|
run make in each of the subdirectories Parser, Objects, Python and
|
|
Modules, creating a library file in each one. The executable of the
|
|
interpreter is built in the Modules subdirectory and moved up here
|
|
when it is built. If you want or need to, you can also chdir into
|
|
each subdirectory in turn and run make there manually (do the Modules
|
|
subdirectory last!).
|
|
|
|
NOTE: if you rerun the configure script with different options, remove
|
|
all object files by running "make clean" before rebuilding. Believe
|
|
it or not, "make clean" sometimes helps to clean up other inexplicable
|
|
problems as well. Try it before sending in a bug report!
|
|
|
|
|
|
Troubleshooting
|
|
---------------
|
|
|
|
If you run into trouble, see section 3 of the FAQ (file Misc/FAQ) for
|
|
hints on what can go wrong, and how to fix it.
|
|
|
|
|
|
Platform specific notes
|
|
-----------------------
|
|
|
|
(Some of these may no longer apply. If you find you can build Python
|
|
on these platforms without the special directions mentioned here, let
|
|
me know so I can remove them!)
|
|
|
|
AIX: Read the file Misc/AIX-NOTES before trying to build.
|
|
|
|
HP-UX: Read the file Misc/HPUX-NOTES if you want to be able to
|
|
use shared libraries for dynamically loaded modules.
|
|
|
|
Minix: When using ack, use "CC=cc AR=aal RANLIB=: ./configure"!
|
|
|
|
SCO: 1) Everything works much better if you add -U__STDC__ to the
|
|
defs. This is because all the SCO header files are broken.
|
|
Anything that isn't mentioned in the C standard it's
|
|
conditionally excluded when __STDC__ is defined.
|
|
|
|
2) Due to the U.S. export restrictions, SCO broke the crypt
|
|
stuff out into a separate library, libcrypt_i.a so the LIBS
|
|
needed be set to:
|
|
|
|
LIBS=' -lsocket -lcrypt_i'
|
|
|
|
|
|
Configuring the set of built-in modules
|
|
---------------------------------------
|
|
|
|
You can configure the interpreter to contain fewer or more built-in
|
|
modules by editing the file Modules/Setup. This file is initially
|
|
copied (when the toplevel Makefile makes Modules/Makefile for the
|
|
first time) from Setup.in; if it does not exist yet, make a copy
|
|
yourself. Never edit Setup.in -- always edit Setup. Read the
|
|
comments in the file for information on what kind of edits you can
|
|
make. When you have edited Setup, Makefile and config.c in Modules
|
|
will automatically be rebuilt the next time you run make in the
|
|
toplevel directory.
|
|
|
|
Especially on SGI IRIX, there are modules that interface to many SGI
|
|
specific system libraries, e.g. the GL library and the audio hardware.
|
|
|
|
|
|
Setting the optimization/debugging options
|
|
------------------------------------------
|
|
|
|
If you want to change the optimization/debugging options for the C
|
|
compiler, assign to the OPT variable on the toplevel make command;
|
|
e.g. "make OPT=-g" will build a debugging version of Python on most
|
|
platforms. The default is OPT=-O; a value for OPT in the environment
|
|
when the configure script is run overrides this default (likewise for
|
|
CC; and the initial value for LIBS is used as the base set of
|
|
libraries to link with).
|
|
|
|
|
|
Testing
|
|
-------
|
|
|
|
To test the interpreter that you have just built, type "make test".
|
|
This runs the test set silently, twice (once with no compiled files,
|
|
once with the compiled files left by the previous test run). Each
|
|
test run should print "All tests OK." and nothing more. (The test set
|
|
does not test the built-in modules, but will find most other problems
|
|
with the interpreter.)
|
|
|
|
IMPORTANT: If the tests fail and you decide to mail a bug report,
|
|
*don't* include the output of "make test". It is useless. Run the
|
|
following command instead:
|
|
|
|
PYTHONPATH=../Lib:../Lib/test:./Modules ./python -c 'import testall'
|
|
|
|
(substituting the top of the source tree for .. if you built in a
|
|
different directory). This gives the output of the tests and shows
|
|
which test failed.
|
|
|
|
|
|
Installing
|
|
----------
|
|
|
|
To install the interpreter as /usr/local/bin/python, type "make
|
|
install". To install the library as /usr/local/lib/python, type "make
|
|
libinstall". To install the manual page as
|
|
/usr/local/man/man1/python.1, type "make maninstall". To install the
|
|
Emacs editing mode for python, manually copy the file
|
|
Misc/python-mode.el to your local Emacs lisp directory. The directory
|
|
/usr/local can be overridden at configuration time by passing
|
|
--prefix=DIRECTORY to the configure script, or at make time by passing
|
|
"prefix=DIRECTORY" to make. See below for more information on --prefix.
|
|
|
|
If you plan to do development of extension modules or to embed Python
|
|
in another application and don't want to reference the original source
|
|
tree, you can type "make inclinstall" and "make libainstall" to
|
|
install the include files and lib*.a files, respectively, as
|
|
/usr/local/include/Py/*.h and /usr/local/lib/python/lib/lib*.a. The
|
|
make libainstall target also installs copies of several other files
|
|
used or produced during the build process which are needed to build
|
|
extensions or to generate their Makefiles.
|
|
|
|
|
|
Configuration options and variables
|
|
-----------------------------------
|
|
|
|
Some special cases are handled by passing environment variables or
|
|
options to the configure script.
|
|
|
|
NOTE: if you rerun the configure script with different options, remove
|
|
all object files by running "make clean" before rebuilding.
|
|
|
|
--with(out)-gcc: The configure script uses gcc (the GNU C compiler) if
|
|
it finds it. If you don't want this, or if this compiler is
|
|
installed but broken on your platform, pass the option
|
|
--without-gcc. You can also pass "CC=cc" (or whatever the
|
|
name of the proper C compiler is) in the environment, but the
|
|
advantage of using --without-gcc is that this option is
|
|
remembered by the config.status script for its --recheck
|
|
option.
|
|
|
|
--prefix, --exec-prefix: If you want to install the binaries and the
|
|
Python library somewhere else than in /usr/local/{bin,lib},
|
|
you can pass the option --prefix=DIRECTORY; the interpreter
|
|
binary will be installed as DIRECTORY/bin/python and the
|
|
library files as DIRECTORY/lib/python/*. If you pass
|
|
--exec-prefix=DIRECTORY (as well) this overrides the
|
|
installation prefix for architecture-dependent files (like the
|
|
interpreter binary). Note that --prefix=DIRECTORY also
|
|
affects the default module search path (sys.path), when
|
|
Modules/config.c is compiled. Passing make the option
|
|
prefix=DIRECTORY (and/or exec_prefix=DIRECTORY) overrides the
|
|
prefix set at configuration time; this may be more convenient
|
|
than re-running the configure script if you change your mind
|
|
about the install prefix...
|
|
|
|
--with-readline: You can use the GNU readline library to improve the
|
|
interactive user interface: this gives you line editing and
|
|
command history when calling python interactively. You need
|
|
to configure build the GNU readline library before running the
|
|
configure script. Its sources are not distributed with
|
|
Python; you can ftp them from any GNU mirror site, or from its
|
|
home site:
|
|
<URL:ftp://slc2.ins.cwru.edu/pub/dist/readline-2.0.tar.gz> (or
|
|
a higher version number -- using version 1.x is not
|
|
recommended).
|
|
|
|
A GPL-free version was posted to comp.sources.misc in volume
|
|
31 and is widely available from FTP archive sites, e.g.
|
|
<URL:ftp://gatekeeper.dec.com/.b/usenet/comp.sources.misc/
|
|
volume31/editline/part01.Z>
|
|
|
|
Pass the Python configure script the option
|
|
--with-readline=DIRECTORY where DIRECTORY is the absolute
|
|
pathname of the directory where you've built the readline
|
|
library. Some hints on building and using the readline
|
|
library are in the FAQ (file Misc/FAQ).
|
|
|
|
--with-thread: On SGI IRIX, and on Sun SOLARIS 2, you can use multiple
|
|
threads. To enable this, pass --with-thread. In the
|
|
Modules/Setup file, enable the thread module. (Threads aren't
|
|
enabled automatically because there are run-time penalties
|
|
when support for them is compiled in even if you don't use
|
|
them.)
|
|
|
|
--with-sgi-dl: On SGI IRIX 4, dynamic loading of extension modules is
|
|
supported by the "dl" library by Jack Jansen, which is
|
|
ftp'able from <URL:ftp://ftp.cwi.nl/pub/dynload/dl-1.6.tar.Z>.
|
|
This is enabled (after you've ftp'ed and compiled the dl
|
|
library!) by passing --with-sgi-dl=DIRECTORY where DIRECTORY
|
|
is the absolute pathname of the dl library. (Don't bother on
|
|
IRIX 5, it already has dynamic linking using SunOS style
|
|
shared libraries.) Support for this feature is deprecated.
|
|
|
|
--with-dl-dld: Dynamic loading of modules is rumoured to be supported
|
|
on some other systems: VAX (Ultrix), Sun3 (SunOS 3.4), Sequent
|
|
Symmetry (Dynix), and Atari ST. This is done using a
|
|
combination of the GNU dynamic loading package
|
|
(<URL:ftp://ftp.cwi.nl/pub/dynload/dl-dld-1.1.tar.Z>) and an
|
|
emulation of the SGI dl library mentioned above (the emulation
|
|
can be found at
|
|
<URL:ftp://ftp.cwi.nl/pub/dynload/dld-3.2.3.tar.Z>). To
|
|
enable this, ftp and compile both libraries, then call the
|
|
configure passing it the option
|
|
--with-dl-dld=DL_DIRECTORY,DLD_DIRECTORY where DL_DIRECTORY is
|
|
the absolute pathname of the dl emulation library and
|
|
DLD_DIRECTORY is the absolute pathname of the GNU dld library.
|
|
(Don't bother on SunOS 4 or 5, they already have dynamic
|
|
linking using shared libraries.) Support for this feature is
|
|
deprecated.
|
|
|
|
--with-libm, --with-libc: It is possible to specify alternative
|
|
versions for the Math library (default -lm) and the C library
|
|
(default the empty string) using the options
|
|
--with-libm=STRING and --with-libc=STRING, respectively. E.g.
|
|
if your system requires that you pass -lc_s to the C compiler
|
|
to use the shared C library, you can pass --with-libc=-lc_s.
|
|
These libraries are passed after all other libraries, the C
|
|
library last.
|
|
|
|
|
|
Extensions
|
|
----------
|
|
|
|
You can also build an "extended" interpreter, using modules that are
|
|
not contained in the Modules directory. Extensions are distributed as
|
|
a separate tar file (currently extensions.tar.gz). See the README
|
|
file there.
|
|
|
|
|
|
Building for multiple architectures (using the VPATH feature)
|
|
-------------------------------------------------------------
|
|
|
|
If your file system is shared between multiple architectures, it
|
|
usually is not necessary to make copies of the sources for each
|
|
architecture you want to support. If the make program supports the
|
|
VPATH feature, you can create an empty build directory for each
|
|
architecture, and in each directory run the configure script (on the
|
|
appropriate machine with the appropriate options). This creates the
|
|
necessary subdirectories and the Makefiles therein. The Makefiles
|
|
contain a line VPATH=... which points to directory containing the
|
|
actual sources. (On SGI systems, use "smake" instead of "make" if you
|
|
use VPATH -- don't try gnumake.)
|
|
|
|
For example, the following is all you need to build a minimal Python
|
|
in /usr/tmp/python (assuming ~guido/src/python is the toplevel
|
|
directory and you want to build in /usr/tmp/python):
|
|
|
|
$ mkdir /usr/tmp/python
|
|
$ cd /usr/tmp/python
|
|
$ ~guido/src/python/configure
|
|
[...]
|
|
$ make
|
|
[...]
|
|
$
|
|
|
|
Note that Modules/Makefile copies the original Setup file to the build
|
|
directory if it finds no Setup file there. This means that you can
|
|
edit the Setup file for each architecture independently. For this
|
|
reason, subsequent changes to the original Setup file are not tracked
|
|
automatically, as they might overwrite local changes. To force a copy
|
|
of a changed original Setup file, delete the target Setup file. (The
|
|
makesetup script supports multiple input files, so if you want to be
|
|
fancy you can change the rules to create an empty Setup.local if it
|
|
doesn't exist and run it with arguments $(srcdir)/Setup Setup.local;
|
|
however this assumes that you only need to add modules.)
|
|
|
|
|
|
Building on non-UNIX systems
|
|
----------------------------
|
|
|
|
On non-UNIX systems, you will have to fake the effect of running the
|
|
configure script manually. A good start is to copy the file
|
|
config.h.in to config.h and edit the latter to reflect the actual
|
|
configuration of your system. Most symbols must simply be defined as
|
|
1 only if the corresponding feature is present and can be left alone
|
|
otherwise; however RETSIGTYPE must always be defined, either as int or
|
|
as void, and the *_t type symbols must be defined as some variant of
|
|
int if they need to be defined at all. Then arrange that the symbol
|
|
HAVE_CONFIG_H is defined during compilation (usually by passing an
|
|
argument of the form `-DHAVE_CONFIG_H' to the compiler, but this is
|
|
necessarily system-dependent).
|
|
|
|
I have tried to collect instructions, Makefiles and additional sources
|
|
for various platforms in this release. The following directories
|
|
exist:
|
|
|
|
Mac/ Apple Macintosh, using THINK C 6.0 or MPW 3.2.
|
|
Dos/ MS-DOS and Windows 3.1, using Microsoft C.
|
|
Nt/ Windows NT, using Microsoft Visual C/C++.
|
|
Os2/ OS/2.
|
|
|
|
Most of these instructions were last tested with a previous Python
|
|
release, so you may still experience occasional problems. If you have
|
|
fixes or suggestions, please let me know and I'll try to incorporate
|
|
them in the next release.
|
|
|
|
|
|
|
|
Miscellaneous issues
|
|
====================
|
|
|
|
|
|
Documentation
|
|
-------------
|
|
|
|
All documentation is provided in the subdirectory Doc in the form of
|
|
LaTeX files. In order of importance for new users: Tutorial (tut),
|
|
Library Reference (lib), Language Reference (ref), Extending (ext).
|
|
Especially the Library Reference is of immense value since much of
|
|
Python's power (including the built-in data types and functions!) is
|
|
described here.
|
|
|
|
To print the documentation from the LaTeX files, chdir into the Doc
|
|
subdirectory, type "make" (let's hope you have LaTeX installed!), and
|
|
send the four resulting PostScript files (tut.ps, lib.ps, ref.ps, and
|
|
ext.ps) to the printer. See the README file there.
|
|
|
|
All documentation is also available on-line via the World-Wide Web
|
|
(WWW): <URL:http://www.cwi.nl/~guido/Python.html>. It can also be
|
|
downloaded separately from the ftp archives (see below) in Emacs INFO,
|
|
HTML or PostScript form -- see the FAQ (file Misc/FAQ) for more info.
|
|
|
|
|
|
Emacs mode
|
|
----------
|
|
|
|
There's an excellent Emacs editing mode for Python code; see the file
|
|
Misc/python-mode.el. Originally written by Tim Peters, who's no
|
|
longer on the net, it is now maintained by Barry Warsaw
|
|
<bwarsaw@cnri.reston.va.com>.
|
|
|
|
BTW, if you want to use font-lock for Python sources, here's something
|
|
to put in your .emacs file:
|
|
|
|
(defun my-python-mode-hook ()
|
|
(setq font-lock-keywords python-font-lock-keywords)
|
|
(font-lock-mode 1))
|
|
(add-hook 'python-mode-hook 'my-python-mode-hook)
|
|
|
|
|
|
|
|
Bug reports
|
|
-----------
|
|
|
|
Bugs are best reported to the comp.lang.python newsgroup or the Python
|
|
mailing list -- see the section "Newsgroup and mailing list" below.
|
|
Before posting, read the FAQ (file Misc/FAQ) first to see if your
|
|
problem has already been answered!
|
|
|
|
|
|
Ftp access
|
|
----------
|
|
|
|
Python's "home ftp site" is ftp.cwi.nl, directory pub/python. See the
|
|
FAQ (file Misc/FAQ) for a list of other ftp sites carrying the Python
|
|
distribution.
|
|
|
|
|
|
Newsgroup and mailing list
|
|
--------------------------
|
|
|
|
There are a newsgroup and a mailing list devoted to Python
|
|
programming, design and bugs. The newsgroup, comp.lang.python,
|
|
contains exactly the same messages as the mailing list. To subscribe
|
|
to the mailing list, send mail containing your real name and e-mail
|
|
address to "python-list-request@cwi.nl" (a real person reads these
|
|
messages, so no LISTPROC or Majordomo commands, please).
|
|
|
|
|
|
The Tk interface
|
|
----------------
|
|
|
|
Tk (the user interface component of John Ousterhout's Tcl language) is
|
|
also usable from Python. Since this requires that you first build and
|
|
install Tcl/Tk, the Tk interface is not enabled by default. It
|
|
requires Tcl 7.4 and Tk 4.0. (Support for Tk 3.6 and Tcl 7.3 can be
|
|
found in Lib/tk3inter/.)
|
|
|
|
To enable the Python/Tk interface, once you've built and installed
|
|
Tcl/Tk, all you need to do is edit two lines in Modules/Setup; search
|
|
for the string "_tkinter". Un-comment one (normally the first) of the
|
|
lines beginning with "#_tkinter" and un-comment the line beginning with
|
|
"#TKPATH". (If you have installed Tcl/Tk in unusual places you will
|
|
have to edit the first line as well to fix the -I and -L options.)
|
|
See the Build Instructions above for more details.
|
|
|
|
There is little documentation. Begin with fetching the "Tk Lifesaver"
|
|
document, e.g. <URL:ftp://ftp.cwi.nl/pub/python/doc/tkinter-doc.tar.gz>
|
|
(a gzipped tar file containing a PostScript file). There are demos in
|
|
the Demo/tkinter directory, in the subdirectories guido, matt and www.
|
|
|
|
Note that there's a Python module called "Tkinter" (capital T) which
|
|
lives in Lib/tkinter/Tkinter.py, and a C module called "tkinter"
|
|
(lower case t) which lives in Modules/_tkinter.c. Demos and
|
|
normal Tk applications only import the Python Tkinter module -- only
|
|
the latter uses the C _tkinter module directly. In order to find the C
|
|
_tkinter module, it must be compiled and linked into the Python
|
|
interpreter -- the _tkinter line in the Setup file does this. In order
|
|
to find the Python Tkinter module, sys.path must be set correctly --
|
|
the TKPATH assignment in the Setup file takes care of this, but only
|
|
if you install Python properly ("make install libinstall"). (You can
|
|
also use dynamic loading for the C _tkinter module, in which case you
|
|
must manually fix up sys.path or set $PYTHONPATH for the Python
|
|
Tkinter module.)
|
|
|
|
See <URL:http://www.smli.com/research/tcl/> for more info on where
|
|
to get Tcl/Tk.
|
|
|
|
|
|
Distribution structure
|
|
----------------------
|
|
|
|
Most subdirectories have their own README file. Most files have
|
|
comments.
|
|
|
|
ChangeLog A raw list of changes since the first 1.0.0 BETA release
|
|
Contrib/ Interesting or useful Python code contributed by others
|
|
Demo/ Demonstration scripts, modules and programs
|
|
Doc/ Documentation (LaTeX sources)
|
|
Extensions/ Extension modules (distributed separately)
|
|
Grammar/ Input for the parser generator
|
|
Include/ Public header files
|
|
Lib/ Python library modules
|
|
Makefile.in Source from which config.status creates Makefile
|
|
Misc/ Miscellaneous files
|
|
Modules/ Implementation of most built-in modules
|
|
Objects/ Implementation of most built-in object types
|
|
Parser/ The parser and tokenizer and their input handling
|
|
Python/ The "compiler" and interpreter
|
|
README The file you're reading now
|
|
Tools/ Some useful programs written in Python
|
|
acconfig.h Additional input for the autoheader program
|
|
config.h.in Source from which config.status creates config.h
|
|
configure Configuration shell script (GNU autoconf output)
|
|
configure.in Configuration specification (GNU autoconf input)
|
|
|
|
The following files will (may) be created in the toplevel directory by
|
|
the configuration and build processes:
|
|
|
|
Makefile Build rules
|
|
config.cache cache of configuration variables
|
|
config.h Configuration header
|
|
config.log log from last configure run
|
|
config.status status from last run of configure script
|
|
python The executable interpreter
|
|
tags, TAGS Tags files for vi and Emacs
|
|
|
|
|
|
Author's address
|
|
----------------
|
|
|
|
Guido van Rossum
|
|
CWI, dept. CST
|
|
P.O. Box 94079
|
|
1090 GB Amsterdam
|
|
The Netherlands
|
|
|
|
E-mail: guido@cwi.nl
|
|
|
|
|
|
|
|
Copyright notice
|
|
================
|
|
|
|
The Python source is copyrighted, but you can freely use and copy it
|
|
as long as you don't change or remove the copyright notice:
|
|
|
|
----------------------------------------------------------------------
|
|
Copyright 1991-1995 by Stichting Mathematisch Centrum, Amsterdam,
|
|
The Netherlands.
|
|
|
|
All Rights Reserved
|
|
|
|
Permission to use, copy, modify, and distribute this software and its
|
|
documentation for any purpose and without fee is hereby granted,
|
|
provided that the above copyright notice appear in all copies and that
|
|
both that copyright notice and this permission notice appear in
|
|
supporting documentation, and that the names of Stichting Mathematisch
|
|
Centrum or CWI not be used in advertising or publicity pertaining to
|
|
distribution of the software without specific, written prior permission.
|
|
|
|
STICHTING MATHEMATISCH CENTRUM DISCLAIMS ALL WARRANTIES WITH REGARD TO
|
|
THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND
|
|
FITNESS, IN NO EVENT SHALL STICHTING MATHEMATISCH CENTRUM BE LIABLE
|
|
FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
|
|
WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
|
|
ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT
|
|
OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
|
|
----------------------------------------------------------------------
|
|
|
|
|
|
--Guido van Rossum, CWI, Amsterdam <mailto:guido@cwi.nl>
|
|
<http://www.cwi.nl/~guido/>
|