| 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/> |