823 lines
33 KiB
Plaintext
823 lines
33 KiB
Plaintext
This is Python release 1.5.1
|
|
============================
|
|
|
|
This version is officially released on Tuesday, April 14, 1997. It is
|
|
mostly a bugfix release on Python 1.5.
|
|
|
|
|
|
What's new in this release?
|
|
---------------------------
|
|
|
|
See the Misc/NEWS file. Nothing spectacular this time, only small
|
|
changes (as you would expect from a release called "1.5.1").
|
|
|
|
One big organizational change: the documentation sources have been
|
|
unbundled. We will release a version of the Doc subtree separately,
|
|
but probably not simultaneously with the source release.
|
|
|
|
|
|
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. :-)
|
|
|
|
|
|
What is Python anyway?
|
|
----------------------
|
|
|
|
Python is an interpreted object-oriented programming language, and is
|
|
often compared to Tcl, Perl, Java or Scheme. To find out more, point
|
|
your browser to http://www.python.org/.
|
|
|
|
|
|
A modest plug
|
|
-------------
|
|
|
|
************************************************************************
|
|
* Without your support, I won't be able to continue to work on Python! *
|
|
************************************************************************
|
|
|
|
If you use Python, please consider joining the Python Software
|
|
Activity (PSA). See http://www.python.org/psa/.
|
|
|
|
Organizations that make heavy use of Python are especially encouraged
|
|
to become corporate members!
|
|
|
|
|
|
How do I learn Python?
|
|
----------------------
|
|
|
|
The official tutorial is still a good place to start (in the Doc
|
|
directory as tut.tex; and http://www.python.org/doc/tut/tut.html).
|
|
Aaron Watters wrote a second tutorial, that may be more accessible for
|
|
some: http://www.wcmh.com/uworld/archives/95/tutorial/005.html. Both
|
|
tutorials (as well as most other sources) assume that you already know
|
|
how to program -- if you'd like to write "Python for Dummies", I know
|
|
a publisher who would like to talk to you...
|
|
|
|
There are now also several books on Python. While these are still
|
|
based on Python 1.3 or 1.4, the information in them is still 99%
|
|
correct. The first two books, both first published in October 1996
|
|
and both including a CD-ROM, form excellent companions to each other:
|
|
|
|
Internet Programming with Python
|
|
by Aaron Watters, Guido van Rossum, and James Ahlstrom
|
|
MIS Press/Henry Holt publishers
|
|
ISBN: 1-55851-484-8
|
|
|
|
Programming Python
|
|
by Mark Lutz
|
|
O'Reilly & Associates
|
|
ISBN: 1-56592-197-6
|
|
|
|
If you can read German, try:
|
|
|
|
Das Python-Buch
|
|
by Martin von Loewis and Nils Fischbeck
|
|
Addison-Wesley-Longman, 1997
|
|
ISBN: 3-8273-1110-1
|
|
|
|
|
|
Copyright issues
|
|
----------------
|
|
|
|
Python is COPYRIGHTED but free to use for all. See the full copyright
|
|
notice at the end of this file and in the file Misc/COPYRIGHT.
|
|
|
|
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.
|
|
|
|
|
|
Build instructions
|
|
==================
|
|
|
|
Before you can build Python, you must first configure it.
|
|
Fortunately, the configuration and build process has been streamlined
|
|
for most Unix installations, so all you have to do is type a few
|
|
commands, optionally edit one file, and sit back. There are some
|
|
platforms where things are not quite as smooth; see the platform
|
|
specific notes below. If you want to build for multiple platforms
|
|
sharing the same source tree, see the section on VPATH below.
|
|
|
|
You start by 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. You may want to pass options to the configure script -- see
|
|
the section below on configuration options and variables.
|
|
|
|
To build Python, you normally type "make" in the toplevel directory.
|
|
This 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!).
|
|
|
|
Once you have built an interpreter, see the subsections below on
|
|
testing, configuring additional modules, and installation. If you run
|
|
in trouble, see the next section.
|
|
|
|
|
|
Troubleshooting
|
|
---------------
|
|
|
|
See also the platform specific notes in the next section.
|
|
|
|
If recursive makes fail, try invoking make as "make MAKE=make".
|
|
|
|
If you run into other trouble, see section 3 of the FAQ
|
|
(http://grail.cnri.reston.va.us/cgi-bin/faqw.py or
|
|
http://www.python.org/doc/FAQ.html) for hints on what can go wrong,
|
|
and how to fix it.
|
|
|
|
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!
|
|
|
|
If the configure script fails or doesn't seem to find things that
|
|
should be there, inspect the config.log file. When you fix a
|
|
configure problem, be sure to remove config.cache!
|
|
|
|
If you get a warning for every file about the -Olimit option being no
|
|
longer supported, you can ignore it. There's no foolproof way to know
|
|
whether this option is needed; all I can do is test whether it is
|
|
accepted without error. On some systems, e.g. older SGI compilers, it
|
|
is essential for performance (specifically when compiling ceval.c,
|
|
which has more basic blocks than the default limit of 1000). If the
|
|
warning bothers you, edit the Makefile to remove "-Olimit 1500" from
|
|
the OPT variable.
|
|
|
|
|
|
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!)
|
|
|
|
64-bit platforms: The modules audioop, imageop and rgbimg don't work.
|
|
Don't try to enable them in the Modules/Setup file. They
|
|
contain code that is quite wordsize sensitive. (If you have a
|
|
fix, let me know!)
|
|
|
|
Solaris: When using Sun's C compiler with threads, at least on Solaris
|
|
2.5.1, you need to add the "-mt" compiler option (the simplest
|
|
way is probably to specify the compiler with this option as
|
|
the "CC" environment variable when running the configure
|
|
script).
|
|
|
|
Linux: On Linux version 1.x, once you've built Python, use it to run
|
|
the regen script in the Lib/linux1 directory. Apparently
|
|
the files as distributed don't match the system headers on
|
|
some Linux versions. (The "h2py" command refers to
|
|
Tools/scripts/h2py.py.) The modules distributed for Linux 2.x
|
|
should be okay. Shared library support now works by default
|
|
on ELF-based x86 Linux systems. (Note: when you change the
|
|
status of a module from static to shared, you must remove its
|
|
.o file or do a "make clean".)
|
|
|
|
Under RedHat Linux 5.0, if upgraded from a previous version,
|
|
remove the LinuxThreads packages. This is needed because
|
|
LinuxThreads conflicts with the new thread support provided by
|
|
glibc. Before running Python's configure script, use the
|
|
following commands as root (version numbers may differ; these
|
|
are from a stock 4.2 install):
|
|
|
|
% rpm -qa | grep ^linuxthread
|
|
linuxthreads-0.5-1
|
|
linuxthreads-devel-0.5-1
|
|
% rpm -e linuxthreads linuxthreads-devel
|
|
|
|
While Python only needs this to be done to allow thread
|
|
support to be included, the conflicts these packages create
|
|
with the new glibc may cause other packages which use threads
|
|
to fail as well, so their removal is a good idea regardless of
|
|
how you configure python.
|
|
|
|
Also under RedHat Linux 5.0, the crypt module now needs the
|
|
-lcrypt option. Uncomment this flag in Modules/Setup, or
|
|
comment out the crypt module in the same file.
|
|
|
|
DEC Unix: When enabling threads, use --with-dec-threads, not
|
|
--with-thread. When using GCC, it is possible to get an
|
|
internal compiler error if optimization is used. This was
|
|
reported for GCC 2.7.2.3 on selectmodule.c. Manually compile
|
|
the affected file without optimization to solve the problem.
|
|
|
|
AIX: A complete overhaul of the shared library support is now in
|
|
place. See Misc/AIX-NOTES for some notes on how it's done.
|
|
(The optimizer bug reported at this place in previous releases
|
|
has been worked around by a minimal code change.)
|
|
|
|
Minix: When using ack, use "CC=cc AR=aal RANLIB=: ./configure"!
|
|
|
|
SCO: The following only apply to SCO 3; Python builds out of the box
|
|
on SCO 5 (or so I've heard).
|
|
|
|
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 is
|
|
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'
|
|
|
|
SunOS 4.x: When using the standard "cc" compiler, certain modules may
|
|
not be compilable because they use non-K&R syntax. You should
|
|
be able to get a basic Python interpreter by commenting out
|
|
such modules in the Modules/Setup file, but I really recommend
|
|
using gcc.
|
|
|
|
When using the SunPro C compiler, you may want to use the
|
|
'-Xa' option instead of '-Xc', to enable some needed non-ANSI
|
|
Sunisms.
|
|
|
|
NeXT: To build fat binaries, use the --with-next-archs switch
|
|
described below.
|
|
|
|
QNX: Chris Herborth (chrish@qnx.com) writes:
|
|
configure works best if you use GNU bash; a port is available on
|
|
ftp.qnx.com in /usr/free. I used the following process to build,
|
|
test and install Python 1.5 under QNX:
|
|
|
|
1) SHELL=/usr/local/bin/bash CC=cc CFLAGS="-5 -O" RANLIB=: \
|
|
bash ./configure --verbose --without-gcc --with-libm=""
|
|
|
|
2) copy Modules/Setup.in to Modules/Setup; edit Modules/Setup to
|
|
activate everything that makes sense for your system... tested
|
|
here at QNX with the following modules:
|
|
|
|
regex reop pcre posix signal readline array cmath math strop
|
|
struct time operator _locale fcntl pwd grp crypt select socket
|
|
errno termios audioop imageop rgbimg md5 timing rotor syslog
|
|
new gdbm soundex binascii parser cStringIO cPickle zlib curses
|
|
|
|
3) SHELL=/usr/local/bin/bash make SHELL=/usr/local/bin/bash
|
|
|
|
4) SHELL=/usr/local/bin/bash make SHELL=/usr/local/bin/bash test
|
|
|
|
The socket, strftime and possibly gdbm tests might fail in the
|
|
test harness; going through them by hand shows that they work.
|
|
A good exercise for the reader: make these work "out of the box".
|
|
|
|
5) SHELL=/usr/local/bin/bash make SHELL=/usr/local/bin/bash install
|
|
|
|
If you get SIGSEGVs while running Python (I haven't yet, but I've
|
|
only run small programs and the test cases), you're probably running
|
|
out of stack; the default 32k could be a little tight. To increase
|
|
the stack size, edit the Makefile in the Modules directory to read:
|
|
LDFLAGS = -N 48k
|
|
|
|
Cray T3E: Konrad Hinsen writes:
|
|
1) Don't use gcc. It compiles Python/graminit.c into something that
|
|
the Cray assembler doesn't like. Cray's cc seems to work fine.
|
|
2) Uncomment modules md5 (won't compile) and audioop (will crash
|
|
the interpreter during the test suite).
|
|
If you run the test suite, two tests will fail (rotate and binascii),
|
|
but these are not the modules you'd expect to need on a Cray.
|
|
|
|
SGI: SGI's standard "make" utility (/bin/make or /usr/bin/make)
|
|
does not check whether a command actually changed the file it
|
|
is supposed to build. This means that whenever you say "make"
|
|
it will redo the link step. The remedy is to use SGI's much
|
|
smarter "smake " utility (/usr/sbin/smake), or GNU make. If
|
|
you set the first line of the Makefile to #!/usr/sbin/smake
|
|
smake will be invoked by make (likewise for GNU make).
|
|
|
|
A bug in the MIPSpro 7.1 compiler's optimizer seems to break
|
|
Modules/pypcre.c. The short term solution is to compile it
|
|
without optimization. The bug appears to be fixed in version
|
|
7.2.1 of the compiler.
|
|
|
|
OS/2: If you are running Warp3 or Warp4 and have IBM's VisualAge C/C++
|
|
compiler installed, just change into the pc\os2vacpp directory
|
|
and type NMAKE. Threading and sockets are supported by default
|
|
in the resulting binaries of PYTHON15.DLL and PYTHON.EXE.
|
|
|
|
|
|
Configuring additional 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. (When working inside the Modules directory, use
|
|
"make Makefile; make".)
|
|
|
|
The default collection of modules should build on any Unix system, but
|
|
many optional modules should work on all modern Unices (e.g. try dbm,
|
|
nis, termios, timing, syslog, curses, new, soundex, parser). Often
|
|
the quickest way to determine whether a particular module works or not
|
|
is to see if it will build: enable it in Setup, then if you get
|
|
compilation or link errors, disable it -- you're missing support.
|
|
|
|
On SGI IRIX, there are modules that interface to many SGI specific
|
|
system libraries, e.g. the GL library and the audio hardware.
|
|
|
|
For SunOS and Solaris, enable module "sunaudiodev" to support the
|
|
audio device.
|
|
|
|
In addition to the file Setup, you can also edit the file Setup.local.
|
|
(the makesetup script processes both). You may find it more
|
|
convenient to edit Setup.local and leave Setup alone. Then, when
|
|
installing a new Python version, you can copy your old Setup.local
|
|
file.
|
|
|
|
|
|
Setting the optimization/debugging options
|
|
------------------------------------------
|
|
|
|
If you want or need 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 twice (once with no compiled files, once with
|
|
the compiled files left by the previous test run). The test set
|
|
produces some output. You can generally ignore the messages about
|
|
skipped tests due to an optional feature that can't be imported (if
|
|
you want to test those modules, edit Modules/Setup to configure them).
|
|
If a messages is printed about a failed test or a traceback or core
|
|
dump is produced, something's wrong. On some Linux systems (those
|
|
that are not yet using glibc 6), test_strftime fails due to a
|
|
non-standard-compliant implementation of strftime() in the C library.
|
|
Please ignore this, or upgrade to glibc version 6.
|
|
|
|
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
|
|
test that fails manually, as follows:
|
|
|
|
python ../Lib/test/test_whatever.py
|
|
|
|
(substituting the top of the source tree for .. if you built in a
|
|
different directory). This runs the test in verbose mode.
|
|
|
|
|
|
Installing
|
|
----------
|
|
|
|
To install the Python binary, library modules, shared library modules
|
|
(see below), include files, configuration files, and the manual page,
|
|
just type
|
|
|
|
make install
|
|
|
|
This will install all platform-independent files in subdirectories the
|
|
directory given with the --prefix option to configure or the 'prefix'
|
|
Make variable (default /usr/local), and all binary and other
|
|
platform-specific files in subdirectories if the directory given by
|
|
--exec-prefix or the 'exec_prefix' Make variable (defaults to the
|
|
--prefix directory).
|
|
|
|
All subdirectories created will have Python's version number in their
|
|
name, e.g. the library modules are installed in
|
|
"/usr/local/lib/python1.5/" by default. The Python binary is
|
|
installed as "python1.5" and a hard link named "python" is created.
|
|
The only file not installed with a version number in its name is the
|
|
manual page, installed as "/usr/local/man/man1/python.1" by default.
|
|
|
|
If you have a previous installation of a pre-1.5 Python that you don't
|
|
want to replace yet, use
|
|
|
|
make altinstall
|
|
|
|
This installs the same set of files as "make install" except it
|
|
doesn't create the hard link to "python1.5" named "python" and it
|
|
doesn't install the manual page at all.
|
|
|
|
The only thing you may have to install manually is the Python mode for
|
|
Emacs. (But then again, more recent versions of Emacs may already
|
|
have it!) This is the file Misc/python-mode.el; follow the
|
|
instructions that came with Emacs for installation of site specific
|
|
files.
|
|
|
|
|
|
Configuration options and variables
|
|
-----------------------------------
|
|
|
|
Some special cases are handled by passing options to the configure
|
|
script.
|
|
|
|
WARNING: if you rerun the configure script with different options, you
|
|
must run "make clean" before rebuilding. Exceptions to this rule:
|
|
after changing --prefix or --exec-prefix, all you need to do is remove
|
|
Modules/getpath.o.
|
|
|
|
--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: This option is no longer supported. To use GNU
|
|
readline, enable module "readline" in the Modules/Setup file.
|
|
|
|
--with-thread: On most Unix systems, you can now use multiple threads.
|
|
To enable this, pass --with-thread. (--with-threads is an
|
|
alias.) If the library required for threads lives in a
|
|
peculiar place, you can use --with-thread=DIRECTORY. NOTE:
|
|
you must also enable the thread module by uncommenting it in
|
|
the Modules/Setup file. (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.) IMPORTANT: run "make
|
|
clean" after changing (either enabling or disabling) this
|
|
option, or you will get link errors! Note: for DEC Unix use
|
|
--with-dec-threads instead.
|
|
|
|
--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 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
|
|
(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
|
|
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.
|
|
|
|
--with-next-archs='arch1 arch2': Under NEXTSTEP, this will build
|
|
all compiled binaries with the architectures listed. Includes
|
|
correctly setting the target architecture specific resource
|
|
directory. (This option is not supported on other platforms.)
|
|
|
|
--with-libs='libs': Add 'libs' to the LIBS that the python
|
|
linked against.
|
|
|
|
|
|
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 -J1" 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
|
|
----------------------------
|
|
|
|
Building Python for a PC is now a piece of cake!
|
|
|
|
Enter the directory "PC" and read the file "readme.txt". Most popular
|
|
non-Unix PC platforms and compilers are supported (Unix ports to the
|
|
PC such as Linux, FreeBSD or Solaris-x86 of course use the standard
|
|
Unix build instructions).
|
|
|
|
For the Mac, a separate source distribution will be made available,
|
|
for use with the CodeWarrior compiler. If you are interested in Mac
|
|
development, join the PythonMac Special Interest Group
|
|
(http://www.python.org/sigs/pythonmac-sig/, or send email to
|
|
pythonmac-sig-request@python.org).
|
|
|
|
Of course, there are also binary distributions available for these
|
|
platforms -- see http://www.python.org/python/.
|
|
|
|
To port Python to a new non-UNIX system, you will have to fake the
|
|
effect of running the configure script manually (for Mac and PC, this
|
|
has already been done for you). 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.
|
|
|
|
|
|
|
|
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. If you don't have
|
|
LaTeX, you can ftp the PostScript files from the ftp archives (see
|
|
below).
|
|
|
|
All documentation is also available on-line via the Python web site
|
|
(http://www.python.org/, see below). It can also be downloaded
|
|
separately from the ftp archives (see below) in Emacs INFO, HTML or
|
|
PostScript form -- see the web site or the FAQ
|
|
(http://grail.cnri.reston.va.us/cgi-bin/faqw.py or
|
|
http://www.python.org/doc/FAQ.html) 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 the famous Tim Peters, it
|
|
is now maintained by the equally famous Barry Warsaw
|
|
<bwarsaw@cnri.reston.va.us>. The latest version is online at
|
|
ftp://ftp.python.org/pub/emacs/python-mode.el. As you might expect of
|
|
Barry (and even if you don't know what the heck I'm talking about :-),
|
|
a configuration file for his cc-mode.el which selects the style used
|
|
throughout most Python C source files is also provided; see the file
|
|
Misc/ccpy-style.el.
|
|
|
|
|
|
Web site
|
|
--------
|
|
|
|
Python's own web site has URL http://www.python.org/. Come visit us!
|
|
There are a number of mirrors, and a list of mirrors is accessible
|
|
from the home page -- try a mirror that's close you you.
|
|
|
|
|
|
Ftp site
|
|
--------
|
|
|
|
Python's own ftp site is ftp://ftp.python.org/pub/python/. There are
|
|
numerous mirrors; the list of mirrors is accessible from
|
|
http://www.python.org/.
|
|
|
|
|
|
Newsgroups
|
|
----------
|
|
|
|
Read comp.lang.python, a high-volume discussion newsgroup about
|
|
Python, or comp.lang.python.announce, a low-volume moderated newsgroup
|
|
for Python-related announcements. These are also accessible as
|
|
mailing lists, see the next item.
|
|
|
|
Archives are accessible via Deja News; the Python website has a
|
|
query form for the archives at http://www.python.org/search/.
|
|
|
|
|
|
Mailing lists
|
|
-------------
|
|
|
|
See http://www.python.org/psa/MailingLists.html for an overview of the
|
|
many Python related mailing lists.
|
|
|
|
|
|
Bug reports
|
|
-----------
|
|
|
|
Bugs are best reported to the comp.lang.python newsgroup (or the
|
|
Python mailing list) -- see the section "Newsgroups" above. Before
|
|
posting, check the newsgroup archives (see above) to see if your bug
|
|
has already been reported! If you don't want to go public, send them
|
|
to me: <guido@python.org>.
|
|
|
|
|
|
Questions
|
|
---------
|
|
|
|
For help, if you can't find it in the manuals or on the web site, it's
|
|
best to post to the comp.lang.python or the Python mailing list (see
|
|
above). If you specifically don't want to involve the newsgroup or
|
|
mailing list, send questions to <python-help@python.org> (a group of
|
|
volunteers which does *not* include me). Because of my work and email
|
|
volume, I'm often be slow in answering questions sent to me directly;
|
|
I prefer to answer questions posted to the newsgroup.
|
|
|
|
|
|
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. Python
|
|
supports all Tcl/Tk versions from version 7.5/4.1 through 8.0 (and it
|
|
is expected that it will also work with newer versions). Tcl/Tk
|
|
7.4/4.0 is no longer supported. 8.0 or any later non-alpha non-beta
|
|
release is recommended.
|
|
|
|
See http://sunscript.sun.com/ for more info on Tcl/Tk, including the
|
|
on-line manual pages.
|
|
|
|
|
|
To enable the Python/Tk interface, once you've built and installed
|
|
Tcl/Tk, load the file Modules/Setup in your favorite text editor and
|
|
search for the string "_tkinter". Then follow the instructions found
|
|
there. If you have installed Tcl/Tk or X11 in unusual places, you
|
|
will have to edit the first line to fix or add -I and -L options.
|
|
(Also see the general instructions at the top of that file.)
|
|
|
|
There is little documentation on how to use Tkinter; however most of
|
|
the Tk manual pages apply quite straightforwardly. Begin with
|
|
fetching the "Tk Lifesaver" document,
|
|
e.g. ftp://ftp.python.org/pub/python/doc/tkinter-doc.tar.gz (a gzipped
|
|
tar file containing a PostScript file) or the on-line version
|
|
http://www.python.org/doc/life-preserver/index.html. Reading the
|
|
Tkinter.py source will reveal most details on how Tkinter calls are
|
|
translated into Tcl code.
|
|
|
|
A more recent introduction to Tkinter programming, by Fredrik Lundh,
|
|
is at http://www.pythonware.com/library/tkinter/introduction/index.htm.
|
|
|
|
There are demos in the Demo/tkinter directory, in the subdirectories
|
|
guido, matt and www (the matt and guido subdirectories have been
|
|
overhauled to use more recent Tkinter coding conventions).
|
|
|
|
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 and leading underscore) 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.)
|
|
|
|
|
|
Distribution structure
|
|
----------------------
|
|
|
|
Most subdirectories have their own README file. Most files have
|
|
comments.
|
|
|
|
Demo/ Demonstration scripts, modules and programs
|
|
Doc/ Documentation (LaTeX sources)
|
|
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 useful files
|
|
Modules/ Implementation of most built-in modules
|
|
Objects/ Implementation of most built-in object types
|
|
PC/ PC porting files (DOS, Windows, OS/2)
|
|
PCbuild/ Directory where you should build for Windows NT/95
|
|
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)
|
|
install-sh Shell script used to install files
|
|
|
|
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
|
|
libpython1.5.a The library archive
|
|
python The executable interpreter
|
|
tags, TAGS Tags files for vi and Emacs
|
|
|
|
|
|
Author's address
|
|
================
|
|
|
|
Guido van Rossum
|
|
CNRI
|
|
1895 Preston White Drive
|
|
Reston, VA 20191
|
|
USA
|
|
|
|
E-mail: guido@cnri.reston.va.us or guido@python.org
|
|
|
|
|
|
|
|
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 or Corporation for National Research Initiatives or
|
|
CNRI not be used in advertising or publicity pertaining to
|
|
distribution of the software without specific, written prior
|
|
permission.
|
|
|
|
While CWI is the initial source for this software, a modified version
|
|
is made available by the Corporation for National Research Initiatives
|
|
(CNRI) at the Internet address ftp://ftp.python.org.
|
|
|
|
STICHTING MATHEMATISCH CENTRUM AND CNRI DISCLAIM ALL WARRANTIES WITH
|
|
REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF
|
|
MERCHANTABILITY AND FITNESS, IN NO EVENT SHALL STICHTING MATHEMATISCH
|
|
CENTRUM OR CNRI 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 (home page: http://www.python.org/~guido/)
|