2094 lines
91 KiB
Plaintext
2094 lines
91 KiB
Plaintext
Subject: FAQ: Python -- an object-oriented language
|
|
Newsgroups: comp.lang.python,comp.answers,news.answers
|
|
Followup-to: comp.lang.python
|
|
From: guido@cwi.nl (Guido van Rossum)
|
|
Reply-to: guido@cnri.reston.va.us (Guido van Rossum)
|
|
Expires: Sun, 1 Oct 1995 00:00:00 GMT
|
|
Supersedes: <DCA29p.A9A@cwi.nl>
|
|
Approved: news-answers-request@MIT.Edu
|
|
|
|
Archive-name: python-faq/part1
|
|
Submitted-by: Guido van Rossum <guido@cwi.nl>
|
|
Version: 1.27
|
|
Last-modified: 28 August 1995
|
|
|
|
This article contains answers to Frequently Asked Questions about
|
|
Python (an object-oriented interpreted programming language -- see
|
|
the answer to question 1.1 for a short overview).
|
|
|
|
Copyright 1993-1995 Guido van Rossum. Unchanged electronic
|
|
redistribution of this FAQ is allowed. Printed redistribution only
|
|
with permission of the author. No warranties.
|
|
|
|
Author's address:
|
|
Guido van Rossum
|
|
C.N.R.I.
|
|
1895 Preston White Drive
|
|
Reston, VA 22091
|
|
U.S.A.
|
|
Email: <guido@python.org>, <guido@cnri.reston.va.us>, <guido@cwi.nl>
|
|
|
|
The latest version of this FAQ is available by anonymous ftp from
|
|
<URL:ftp://ftp.python.org/pub/python/FAQ>. It will also be posted
|
|
regularly to the newsgroups comp.answers <URL:news:comp.answers> and
|
|
comp.lang.python <URL:news:comp.lang.python>.
|
|
|
|
Many FAQs, including this one, are available by anonymous ftp
|
|
<URL:ftp://rtfm.mit.edu/pub/usenet/news.answers/>. The name under
|
|
which a FAQ is archived appears in the Archive-name line at the top of
|
|
the article. This FAQ is archived as python-faq/part1
|
|
<URL:ftp://rtfm.mit.edu/pub/usenet/news.answers/python-faq/part1>.
|
|
|
|
There's a mail server on that machine which will send you files from
|
|
the archive by e-mail if you have no ftp access. You send a e-mail
|
|
message to <mail-server@rtfm.mit.edu> containing the single word help
|
|
in the message body to receive instructions.
|
|
|
|
This FAQ is divided in the following chapters:
|
|
|
|
1. General information and availability
|
|
2. Python in the real world
|
|
3. Building Python and Other Known Bugs
|
|
4. Programming in Python
|
|
5. Extending Python
|
|
6. Python's design
|
|
7. Using Python on non-UNIX platforms
|
|
|
|
To find the start of a particular chapter, search for the chapter number
|
|
followed by a dot and a space at the beginning of a line (e.g. to
|
|
find chapter 4 in vi, type /^4\. /).
|
|
|
|
Here's an overview of the questions per chapter:
|
|
|
|
1. General information and availability
|
|
1.1. Q. What is Python?
|
|
1.2. Q. Why is it called Python?
|
|
1.3. Q. How do I obtain a copy of the Python source?
|
|
1.4. Q. How do I get documentation on Python?
|
|
1.5. Q. Are there other ftp sites that mirror the Python distribution?
|
|
1.6. Q. Is there a newsgroup or mailing list devoted to Python?
|
|
1.7. Q. Is there a WWW page devoted to Python?
|
|
1.8. Q. Is the Python documentation available on the WWW?
|
|
1.9. Q. Is there a book on Python, or will there be one out soon?
|
|
1.10. Q. Are there any published articles about Python that I can quote?
|
|
1.11. Q. Are there short introductory papers or talks on Python?
|
|
1.12. Q. How does the Python version numbering scheme work?
|
|
1.13. Q. How do I get a beta test version of Python?
|
|
1.14. Q. Are there other ftp sites that carry Python related material?
|
|
1.15. Q. Are there copyright restrictions on the use of Python?
|
|
1.16. Q. Why was Python created in the first place?
|
|
1.17. Q. What happened to Tim Peters (the author of python-mode.el, and many
|
|
entertaining and enlightening pieces of Python email)?
|
|
|
|
2. Python in the real world
|
|
2.1. Q. How many people are using Python?
|
|
2.2. Q. Have any significant projects been done in Python?
|
|
2.3. Q. Are there any commercial projects going on using Python?
|
|
2.4. Q. How stable is Python?
|
|
2.5. Q. When will the next version be released?
|
|
2.6. Q. What new developments are expected for Python in the future?
|
|
2.7. Q. Is it reasonable to propose incompatible changes to Python?
|
|
2.8. Q. What is the future of Python?
|
|
|
|
3. Building Python and Other Known Bugs
|
|
3.1. Q. Is there a test set?
|
|
3.2. Q. When running the test set, I get complaints about floating point
|
|
operations, but when playing with floating point operations I cannot
|
|
find anything wrong with them.
|
|
3.3. Q. Link errors after rerunning the configure script.
|
|
3.4. Q. The python interpreter complains about options passed to a
|
|
script (after the script name).
|
|
3.5. Q. When building on the SGI, make tries to run python to create
|
|
glmodule.c, but python hasn't been built or installed yet.
|
|
3.6. Q. Python built with gcc for the DEC Alpha doesn't work.
|
|
3.7. Q. I use VPATH but some targets are built in the source directory.
|
|
3.8. Q. Trouble building or linking with the GNU readline library.
|
|
3.9. Q. Trouble building Python on Linux.
|
|
3.10. Q. Trouble with prototypes on Ultrix.
|
|
3.11. Q. Trouble with posix.listdir on NeXTSTEP 3.2.
|
|
3.12. Q. Other trouble building Python on platform X.
|
|
3.13. Q. How to configure dynamic loading on Lixux.
|
|
3.14. Q. Under Solaris 2.x, using GCC, how do I use shared libraries?
|
|
3.15. Q. Errors when linking with a shared library containing C++ code.
|
|
3.16. Q. Tk menus don't work properly in Python 1.2
|
|
3.17. Q. I built with tkintermodule.c enabled but get "Tkinter not found"
|
|
3.18. Q. I built with Tk 4.0 but Tkinter complains about the Tk version
|
|
3.19. Q. Tk doesn't work right on DEC Alpha
|
|
|
|
4. Programming in Python
|
|
4.1. Q. Is there a source code level debugger with breakpoints, step,
|
|
etc.?
|
|
4.2. Q. Can I create an object class with some methods implemented in
|
|
C and others in Python (e.g. through inheritance)? (Also phrased as:
|
|
Can I use a built-in type as base class?)
|
|
4.3. Q. Is there a curses/termcap package for Python?
|
|
4.4. Q. Is there an equivalent to C's onexit() in Python?
|
|
4.5. Q. When I define a function nested inside another function, the
|
|
nested function seemingly can't access the local variables of the
|
|
outer function. What is going on? How do I pass local data to a
|
|
nested function?
|
|
4.6. Q. How do I iterate over a sequence in reverse order?
|
|
4.7. Q. My program is too slow. How do I speed it up?
|
|
4.8. Q. When I have imported a module, then edit it, and import it
|
|
again (into the same Python process), the changes don't seem to take
|
|
place. What is going on?
|
|
4.9. Q. How do I find the current module name?
|
|
4.10. Q. I have a module in which I want to execute some extra code
|
|
when it is run as a script. How do I find out whether I am running as
|
|
a script?
|
|
4.11. Q. I try to run a program from the Demo directory but it fails
|
|
with ImportError: No module named ...; what gives?
|
|
4.12. Q. I have successfully built Python with STDWIN but it can't
|
|
find some modules (e.g. stdwinevents).
|
|
4.13. Q. What GUI toolkits exist for Python?
|
|
4.14. Q. Are there any interfaces to database packages in Python?
|
|
4.15. Q. Is it possible to write obfuscated one-liners in Python?
|
|
4.16. Q. Is there an equivalent of C's "?:" ternary operator?
|
|
4.17. Q. My class defines __del__ but it is not called when I delete the
|
|
object.
|
|
4.18. Q. How do I change the shell environment for programs called
|
|
using os.popen() or os.system()? Changing os.environ doesn't work.
|
|
4.19. Q. What is a class?
|
|
4.20. Q. What is a method?
|
|
4.21. Q. What is self?
|
|
4.22. Q. What is a unbound method?
|
|
4.23. Q. How do I call a method defined in a base class from a derived
|
|
class that overrides it?
|
|
4.24. Q. How do I call a method from a base class without using the
|
|
name of the base class?
|
|
4.25. Q. How can I organize my code to make it easier to change the base
|
|
class?
|
|
4.26. Q. How can I find the methods or attributes of an object?
|
|
4.27. Q. I can't seem to use os.read() on a pipe created with os.popen().
|
|
4.28. Q. How can I create a stand-alone binary from a Python script?
|
|
4.29. Q. What WWW tools are there for Python?
|
|
4.30. Q. How do I run a subprocess with pipes connected to both input
|
|
and output?
|
|
4.31. Q. How do I call a function if I have the arguments in a tuple?
|
|
4.32. Q. How do I enable font-lock-mode for Python in Emacs?
|
|
4.33. Q. Is there an inverse to the format operator (a la C's scanf())?
|
|
|
|
5. Extending Python
|
|
5.1. Q. Can I create my own functions in C?
|
|
5.2. Q. Can I create my own functions in C++?
|
|
5.3. Q. How can I execute arbitrary Python statements from C?
|
|
5.4. Q. How can I evaluate an arbitrary Python expression from C?
|
|
5.5. Q. How do I extract C values from a Python object?
|
|
5.6. Q. How do I use mkvalue() to create a tuple of arbitrary length?
|
|
5.7. Q. What happened to mktuple(), featured in an example in the
|
|
Extensions manual?
|
|
5.8. Q. How do I call an object's method from C?
|
|
5.9. Q. How do I catch the output from print_error()?
|
|
5.10. Q. How do I access a module written in Python from C?
|
|
5.11. Q. How do I interface to C++ objects from Python?
|
|
|
|
6. Python's design
|
|
6.1. Q. Why isn't there a generic copying operation for objects in Python?
|
|
6.2. Q. Why isn't there a generic way to implement persistent objects
|
|
in Python? (Persistent == automatically saved to and restored from
|
|
disk.)
|
|
6.3. Q. Why isn't there a switch or case statement in Python?
|
|
6.4. Q. Why does Python use indentation for grouping of statements?
|
|
6.5. Q. Why are Python strings immutable?
|
|
6.6. Q. Why don't strings have methods like index() or sort(), like
|
|
lists?
|
|
6.7. Q. Why does Python use methods for some functionality
|
|
(e.g. list.index()) but functions for other (e.g. len(list))?
|
|
6.8. Q. Why can't I derive a class from built-in types (e.g. lists or
|
|
files)?
|
|
6.9. Q. Why must 'self' be declared and used explicitly in method
|
|
definitions and calls?
|
|
6.10. Q. Can't you emulate threads in the interpreter instead of
|
|
relying on an OS-specific thread implementation?
|
|
6.11. Q. Why can't lambda forms contain statements?
|
|
6.12. Q. Why is there no more efficient way of iterating over a dictionary
|
|
than first constructing the list of keys()?
|
|
6.13. Q. Can Python be compiled to machine code, C or some other language?
|
|
|
|
7. Using Python on non-UNIX platforms
|
|
7.1. Q. Is there a Mac version of Python?
|
|
7.2. Q. Is there a DOS version of Python?
|
|
7.3. Q. Is there a Windows 3.1(1) version of Python?
|
|
7.4. Q. Is there a Windows NT version of Python?
|
|
7.5. Q. Is there a Windows 95 version of Python?
|
|
7.6. Q. Is there an OS/2 version of Python?
|
|
7.7. Q. Is there a VMS version of Python?
|
|
7.8. Q. What about IBM mainframes, or other non-UNIX platforms?
|
|
7.9. Q. Where are the source or Makefiles for the non-UNIX versions?
|
|
7.10. Q. What is the status and support for the non-UNIX versions?
|
|
7.11. Q. I have a PC version but it appears to be only a binary.
|
|
Where's the library?
|
|
7.12. Q. Where's the documentation for the Mac or PC version?
|
|
7.13. Q. The Mac (PC) version doesn't seem to have any facilities for
|
|
creating or editing programs apart from entering it interactively, and
|
|
there seems to be no way to save code that was entered interactively.
|
|
How do I create a Python program on the Mac (PC)?
|
|
|
|
To find a particular question, search for the question number followed
|
|
by a dot, a space, and a Q at the beginning of a line (e.g. to find
|
|
question 4.2 in vi, type /^4\.2\. Q/).
|
|
|
|
|
|
1. General information and availability
|
|
=======================================
|
|
|
|
1.1. Q. What is Python?
|
|
|
|
A. Python is an interpreted, interactive, object-oriented programming
|
|
language. It incorporates modules, exceptions, dynamic typing, very
|
|
high level dynamic data types, and classes. Python combines
|
|
remarkable power with very clear syntax. It has interfaces to many
|
|
system calls and libraries, as well as to various window systems, and
|
|
is extensible in C or C++. It is also usable as an extension language
|
|
for applications that need a programmable interface. Finally, Python
|
|
is portable: it runs on many brands of UNIX, on the Mac, and on PCs
|
|
under MS-DOS, Windows, Windows NT, and OS/2.
|
|
|
|
To find out more, the best thing to do is to start reading the
|
|
tutorial from the documentation set (see a few questions further
|
|
down).
|
|
|
|
1.2. Q. Why is it called Python?
|
|
|
|
A. Apart from being a computer scientist, I'm also a fan of "Monty
|
|
Python's Flying Circus" (a BBC comedy series from the seventies, in
|
|
the -- unlikely -- case you didn't know). It occurred to me one day
|
|
that I needed a name that was short, unique, and slightly mysterious.
|
|
And I happened to be reading some scripts from the series at the
|
|
time... So then I decided to call my language Python. But Python is
|
|
not a joke. And don't you associate it with dangerous reptiles
|
|
either! (If you need an icon, use an image of the 16-ton weight from
|
|
the TV series or of a can of SPAM :-)
|
|
|
|
1.3. Q. How do I obtain a copy of the Python source?
|
|
|
|
A. The latest complete Python source distribution is always available
|
|
by anonymous ftp, e.g.
|
|
<URL:ftp://ftp.python.org/pub/python/src/python1.2.tar.gz>. It is a
|
|
gzipped tar file containing the complete C source, LaTeX
|
|
documentation, Python library modules, example programs, and several
|
|
useful pieces of freely distributable software. This will compile and
|
|
run out of the box on most UNIX platforms. (See section 7 for
|
|
non-UNIX information.)
|
|
|
|
Occasionally a set of patches is issued which has to be applied using
|
|
the patch program. These patches are placed in the same directory,
|
|
e.g. <URL:ftp://ftp.python.org/pub/python/src/patch1.1.1>. (At the time
|
|
of writing, no patches exist for 1.2.)
|
|
|
|
An index of said ftp directory can be found in the file INDEX. An
|
|
HTML version of the index can be found in the file index.html,
|
|
<URL:ftp://ftp.python.org/pub/python/index.html>.
|
|
|
|
1.4. Q. How do I get documentation on Python?
|
|
|
|
A. The LaTeX source for the documentation is part of the source
|
|
distribution. If you don't have LaTeX, the latest Python
|
|
documentation set is always available by anonymous ftp, e.g.
|
|
<URL:ftp://ftp.python.org/pub/python/doc/postscript.tar.gz>. It is a
|
|
gzipped tar file containing PostScript files of the reference manual,
|
|
the library manual, and the tutorial. Note that the library manual is
|
|
the most important one of the set, as much of Python's power stems
|
|
from the standard or built-in types, functions and modules, all of
|
|
which are described here. PostScript for a high-level description of
|
|
Python is in the file nluug-paper.ps (a separate file on the ftp
|
|
site).
|
|
|
|
1.5. Q. Are there other ftp sites that mirror the Python distribution?
|
|
|
|
A. The following anonymous ftp sites keep mirrors of the Python
|
|
distribution:
|
|
|
|
<URL:ftp://ftp.cwi.nl/pub/python/>
|
|
<URL:ftp://gatekeeper.dec.com/pub/plan/python/>
|
|
<URL:ftp://ftp.uu.net/languages/python/>
|
|
<URL:ftp://ftp.wustl.edu/graphics/graphics/sgi-stuff/python/>
|
|
<URL:ftp://ftp.funet.fi/pub/languages/python/>
|
|
<URL:ftp://ftp.sunet.se/pub/lang/python/>
|
|
<URL:ftp://unix.hensa.ac.uk/mirrors/uunet/languages/python/>
|
|
<URL:ftp://ftp.sterling.com/programming/languages/python/>
|
|
<URL:ftp://ftp.ibp.fr/pub/python/>
|
|
<URL:ftp://ftp.switch.ch/software/sources/python/>
|
|
<URL:ftp://ftp.informatik.tu-muenchen.de/pub/comp/programming/languages/python/>
|
|
|
|
Or try archie on the string "python".
|
|
|
|
1.6. Q. Is there a newsgroup or mailing list devoted to Python?
|
|
|
|
A. There is a newsgroup, comp.lang.python <URL:news:comp.lang.python>,
|
|
and a mailing list. The newsgroup and mailing list are gatewayed into
|
|
each other -- if you can read news it's unnecessary to subscribe to
|
|
the mailing list. Send e-mail to <python-list-request@cwi.nl> to
|
|
(un)subscribe to the mailing list. Hypermail archives of (nearly)
|
|
everything posted to the mailing list (and thus the newsgroup) are
|
|
available on our WWW server,
|
|
<URL:http://www.cwi.nl/~guido/hypermail/index.html>. The raw archives
|
|
are also available by ftp, e.g.
|
|
<URL:ftp://ftp.python.org/pub/python/mail/mailinglist.gz>. The
|
|
uncompressed versions of these files can be read with the standard
|
|
UNIX Mail program ("Mail -f file") or with nn ("nn file"). To read
|
|
them using MH, you could use "inc -file file". (The archival service
|
|
has stopped archiving new articles around the end of April 1995. I
|
|
hope to revive it on the PSA server www.python.org sometime in the
|
|
future.)
|
|
|
|
1.7. Q. Is there a WWW page devoted to Python?
|
|
|
|
A. Yes, <URL:http://www.python.org/> is the official Python home page.
|
|
At the time of writing, this page is not yet completely operational;
|
|
you may have a look at the old Python home page:
|
|
<URL:http://www.cwi.nl/~guido/Python.html> or at the U.S. copy:
|
|
<URL:http://www.python.org/~guido/Python.html>.
|
|
|
|
1.8. Q. Is the Python documentation available on the WWW?
|
|
|
|
A. Yes, see <URL:http://www.python.org/> (Python's home page). It
|
|
contains pointers to hypertext versions of the whole documentation set
|
|
(as hypertext, not just PostScript).
|
|
|
|
If you wish to browse this collection of HTML files on your own
|
|
machine, it is available bundled up by anonymous ftp,
|
|
e.g. <URL:ftp://ftp.python.org/pub/python/doc/html.tar.gz>.
|
|
|
|
An Emacs-INFO set containing the library manual is also available by
|
|
ftp, e.g. <URL:ftp://ftp.python.org/pub/python/doc/lib-info.tar.gz>.
|
|
|
|
1.9. Q. Is there a book on Python, or will there be one out soon?
|
|
|
|
A. Mark Lutz is writing a Python book for O'Reilly and Associates, to
|
|
be published early 1996. See the outline (in PostScript):
|
|
<URL:http://www.python.org/workshops/1995-05/outlinep.eps>.
|
|
|
|
1.10. Q. Are there any published articles about Python that I can quote?
|
|
|
|
A. So far the only refereed and published article that describes
|
|
Python in some detail is:
|
|
|
|
Guido van Rossum and Jelke de Boer, "Interactively Testing Remote
|
|
Servers Using the Python Programming Language", CWI Quarterly, Volume
|
|
4, Issue 4 (December 1991), Amsterdam, pp 283-303.
|
|
|
|
LaTeX source for this paper is available as part of the Python source
|
|
distribution.
|
|
|
|
1.11. Q. Are there short introductory papers or talks on Python?
|
|
|
|
A. A recent high-level description of Python is:
|
|
|
|
Guido van Rossum, "An Introduction to Python for UNIX/C
|
|
Programmers", in the proceedings of the NLUUG najaarsconferentie
|
|
1993 (dutch UNIX users group meeting November 1993).
|
|
|
|
PostScript for this paper and for the slides used for the accompanying
|
|
presentation is available by ftp as
|
|
<URL:ftp://ftp.python.org/pub/python/doc/nluug-paper.ps> and
|
|
<URL:ftp://ftp.python.org/pub/python/doc/nluug-slides.ps>, respectively.
|
|
|
|
Slides for a talk on Python that I gave at the Usenix Symposium on
|
|
Very High Level Languages in Santa Fe, NM, USA in October 1995 are
|
|
available as <URL:ftp://ftp.python.org/pub/python/doc/vhll-slides.ps>.
|
|
|
|
1.12. Q. How does the Python version numbering scheme work?
|
|
|
|
A. Python versions are numbered A.B.C. A is the major version number
|
|
-- it is only incremented for major changes in functionality or source
|
|
structure. B is the minor version number, incremented for less
|
|
earth-shattering changes to a release. C is the patchlevel -- it is
|
|
incremented for each new release. Note that in the past, patches have
|
|
added significant changes; in fact the changeover from 0.9.9 to 1.0.0
|
|
was the first time that either A or B changed!
|
|
|
|
Beta versions have an additional suffix of "-beta-N" for some small
|
|
number N. Note that (for instance) all versions labeled 1.2-beta-N
|
|
*precede* the actual release of 1.2.
|
|
|
|
1.13. Q. How do I get a beta test version of Python?
|
|
|
|
A. Write me. I might like you :-) Seriously, anybody who has
|
|
previously used and installed Python can become a beta tester, but I
|
|
expect feedback, so you have to write me first before I divulge the
|
|
secret location of the latest beta release.
|
|
|
|
1.14. Q. Are there other ftp sites that carry Python related material?
|
|
|
|
A. An interesting ftp site for Python users is ftp.markv.com; the
|
|
directory pub/python contains a growing collection of interesting
|
|
Python scripts <URL:ftp://ftp.markv.com/pub/python/>. To submit a
|
|
script for inclusion, place it together with a readme file (with
|
|
extension .readme) in the publicly writable directory
|
|
/incoming/python. This service is maintained by Lance Ellinghaus
|
|
<lance@markv.com>. (I've heard complaints about this service not
|
|
being very responsive -- try at your own risk.)
|
|
|
|
1.15. Q. Are there copyright restrictions on the use of Python?
|
|
|
|
A. Hardly. You can do anything you want with the source, as long as
|
|
you leave the copyrights in, and display those copyrights in any
|
|
documentation about Python that you produce. Also, don't use the
|
|
author's institute's name in publicity without prior written
|
|
permission, and don't hold them responsible for anything (read the
|
|
actual copyright for a precise legal wording).
|
|
|
|
In particular, if you honor the copyright rules, it's OK to use Python
|
|
for commercial use, to sell copies of Python in source or binary form,
|
|
or to sell products that enhance Python or incorporate Python (or part
|
|
of it) in some form. I would still like to know about all commercial
|
|
use of Python!
|
|
|
|
1.16. Q. Why was Python created in the first place?
|
|
|
|
A. Here's a *very* brief summary of what got me started:
|
|
|
|
- I had extensive experience with implementing an interpreted language
|
|
in the ABC group at CWI, and from working with this group I had
|
|
learned a lot about language design. This is the origin of many
|
|
Python features, including the use of indentation for statement
|
|
grouping and the inclusion of very-high-level data types (although the
|
|
details are all different in Python).
|
|
|
|
- I had a number of gripes about the ABC language, but also liked many
|
|
of its features. It was impossible to extend the ABC language (or its
|
|
implementation) to remedy my complaints -- in fact its lack of
|
|
extensibility was one of its biggest problems.
|
|
|
|
- I had some experience with using Modula-2+ and talked with the
|
|
designers of Modula-3 (and read the M3 report). M3 is the origin of
|
|
the syntax and semantics used for exceptions, and some other Python
|
|
features.
|
|
|
|
- I was working in the Amoeba distributed operating system group at
|
|
CWI. We needed a better way to do system administration than by
|
|
writing either C programs or Bourne shell scripts, since Amoeba had
|
|
its own system call interface which wasn't easily accessible from the
|
|
Bourne shell. My experience with error handling in Amoeba made me
|
|
acutely aware of the importance of exceptions as a programming
|
|
language feature.
|
|
|
|
- It occurred to me that a scripting language with a syntax like ABC
|
|
but with access to the Amoeba system calls would fill the need. I
|
|
realized that it would be foolish to write an Amoeba-specific
|
|
language, so I decided that I needed a language that was generally
|
|
extensible.
|
|
|
|
- During the 1989 Christmas holidays, I had a lot of time on my hand,
|
|
so I decided to give it a try. During the next year, while still
|
|
mostly working on it in my own time, Python was used in the Amoeba
|
|
project with increasing success, and the feedback from colleagues made
|
|
me add many early improvements.
|
|
|
|
- In February 1991, after just over a year of development, I decided
|
|
to post to USENET. The rest is in the Misc/HISTORY file.
|
|
|
|
1.17. Q. What happened to Tim Peters (the author of python-mode.el, and many
|
|
entertaining and enlightening pieces of Python email)?
|
|
|
|
A. He worked at KSR (Kendall Square Research, a start-up building a
|
|
new kind of massively parallel processor). When KSR folded down a
|
|
couple of years ago, Tim lost his email access. He hasn't surfaced
|
|
on the net since then.
|
|
|
|
Missing-him-too-ly yours...
|
|
|
|
PS: support for Python's Emacs mode (Misc/python-mode.el in the
|
|
distribution) has been taken up by Barry Warsaw. Questions about it
|
|
should be mailed to <python-mode@python.org>.
|
|
|
|
|
|
2. Python in the real world
|
|
===========================
|
|
|
|
2.1. Q. How many people are using Python?
|
|
|
|
A. I don't know, but the maximum number of simultaneous subscriptions
|
|
to the Python mailing list before it was gatewayed into the newsgroup
|
|
was about 180 (several of which were local redistribution lists). I
|
|
believe that many active Python users don't bother to subscribe to the
|
|
list, and now that there's a newsgroup the mailing list subscription
|
|
is even less meaningful. I see new names on the newsgroup all the
|
|
time and my best guess is that there are currently at least several
|
|
thousands of users.
|
|
|
|
Another statistic is the number of accesses to the Python WWW server.
|
|
Have a look at <URL:http://www.python.org/stats/>.
|
|
|
|
2.2. Q. Have any significant projects been done in Python?
|
|
|
|
A. Here at CWI (the home of Python), we have written a 20,000 line
|
|
authoring environment for transportable hypermedia presentations, a
|
|
5,000 line multimedia teleconferencing tool, as well as many many
|
|
smaller programs.
|
|
|
|
The University of Virginia uses Python to control a virtual reality
|
|
engine. Contact: Matt Conway <conway@virginia.edu>.
|
|
|
|
The ILU project at Xerox PARC can generate Python glue for ILU
|
|
interfaces. See <URL:ftp://ftp.parc.xerox.com/pub/ilu/ilu.html>.
|
|
|
|
The University of California, Irvine uses a student administration
|
|
system called TELE-Vision written entirely in Python. Contact: Ray
|
|
Price <rlprice@uci.edu>.
|
|
|
|
See also the next question.
|
|
|
|
If you have done a significant project in Python that you'd like to be
|
|
included in the list above, send me email!
|
|
|
|
2.3. Q. Are there any commercial projects going on using Python?
|
|
|
|
A. Several companies have revealed to me that they are planning or
|
|
considering use of Python in a future product.
|
|
|
|
Sunrise Software has a product out using Python -- they use Python
|
|
for a GUI management application and an SNMP network management
|
|
application. Contact: <info@sunrise.com>.
|
|
|
|
Infoseek uses Python to implement their commercial WWW information
|
|
retrieval service <URL:http://www.infoseek.com/>. Contact:
|
|
<info@infoseek.com>.
|
|
|
|
Michael Powers of daVinci Time & Space is "writing tons-o-python for
|
|
interactive television entertainment." Contact: <powers@dvts.com>.
|
|
|
|
Paul Everitt of Connecting Minds is planning a Lotus Notes gateway.
|
|
Contact: <Paul.Everitt@cminds.com>. Or see their WWW server
|
|
<URL:http://www.cminds.com/>.
|
|
|
|
KaPRE in Boulder, CO is using Python for on-site customization of C++
|
|
applications, rapid-prototyping/development,
|
|
language-based-components, and possibly more. This is pretty solid:
|
|
Python's being shipped with their tool-set now, to beta sites.
|
|
Contact: <lutz@KaPRE.COM> (Mark Lutz).
|
|
|
|
Individuals at many other companies are using Python for internal
|
|
development or for as yet unannounced products (witness their
|
|
contributions to the Python mailing list or newsgroup).
|
|
|
|
SGI has advertised in the Python list looking for Python programmers
|
|
for a project involving interactive television.
|
|
|
|
See also the workshop minutes at
|
|
<URL:http://www.python.org/workshops/> -- in general the WWW server is
|
|
more up to date than the FAQ for these issues.
|
|
|
|
Python has also been elected as an extension language by MADE, a
|
|
consortium supported by the European Committee's ESPRIT program and
|
|
consisting of Bull, CWI and some other European companies. Contact:
|
|
Ivan Herman <ivan@cwi.nl>.
|
|
|
|
If you'd like to be included in the list above, send me email!
|
|
|
|
2.4. Q. How stable is Python?
|
|
|
|
A. Very stable. While the current version number would suggest it is
|
|
in the early stages of development, in fact new, stable releases
|
|
(numbered 0.9.x through 1.2) have been coming out roughly every 3 to
|
|
6 months for the past four years.
|
|
|
|
2.5. Q. When will the next version be released?
|
|
|
|
A. I am planning to release 1.3 in early October 1995. It will
|
|
contain keyword parameters as the most important new language feature.
|
|
A beta version was made available in August, more beta versions may
|
|
appear.
|
|
|
|
2.6. Q. What new developments are expected for Python in the future?
|
|
|
|
A. See my Work-In-Progress web page, currently at
|
|
<URL:http://www.python.org:~guido/WIP.html>, and the pages for the
|
|
Second Python Workshop (best reached via the Python home page,
|
|
<URL:http://www.python.org/>). Also follow the newsgroup discussions!
|
|
|
|
2.7. Q. Is it reasonable to propose incompatible changes to Python?
|
|
|
|
A. In general, no. There are already millions of lines of Python code
|
|
around the world, so any changes in the language that invalidates more
|
|
than a very small fraction of existing programs has to be frowned
|
|
upon. Even if you can provide a conversion program, there still is
|
|
the problem of updating all documentation. Providing a gradual
|
|
upgrade path is the only way if a feature has to be changed.
|
|
|
|
2.8. Q. What is the future of Python?
|
|
|
|
A. If I knew, I'd be rich :-)
|
|
|
|
Seriously, the formation of the PSA (Pyton Software Activity, see
|
|
<URL:http://www.python.org/psa/>) ensures some kind of support even in
|
|
the (unlikely! event that I'd be hit by a bus (actually, here in the
|
|
US, a car accident would be more likely :-), were to join a nunnery,
|
|
or would be head-hunted. A large number of Python users have become
|
|
experts at Python programming as well as maintenance of the
|
|
implementation, and would easily fill the vacuum created by my
|
|
disappearance.
|
|
|
|
In the mean time, I have no plans to disappear -- rather, I am
|
|
committed to improving Python, and my current benefactor, CNRI (see
|
|
<URL:http://www.cnri.reston.va.us>) is just as committed to continue
|
|
its support of Python and the PSA. In fact, we have great plans for
|
|
Python -- we just can't tell yet!
|
|
|
|
|
|
3. Building Python and Other Known Bugs
|
|
=======================================
|
|
|
|
3.1. Q. Is there a test set?
|
|
|
|
A. Yes, simply do "import testall" (or "import autotest" if you aren't
|
|
interested in the output). The standard modules whose name begins
|
|
with "test" together comprise the test. The test set doesn't test
|
|
*all* features of Python but it goes a long way to confirm that a new
|
|
port is actually working. The Makefile contains an entry "make test"
|
|
which runs the autotest module. NOTE: if "make test" fails, run the
|
|
tests manually ("import testall") to see what goes wrong before
|
|
reporting the error.
|
|
|
|
3.2. Q. When running the test set, I get complaints about floating point
|
|
operations, but when playing with floating point operations I cannot
|
|
find anything wrong with them.
|
|
|
|
A. The test set makes occasional unwarranted assumptions about the
|
|
semantics of C floating point operations. Until someone donates a
|
|
better floating point test set, you will have to comment out the
|
|
offending floating point tests and execute similar tests manually.
|
|
|
|
3.3. Q. Link errors after rerunning the configure script.
|
|
|
|
A. It is generally necessary to run "make clean" after a configuration
|
|
change.
|
|
|
|
3.4. Q. The python interpreter complains about options passed to a
|
|
script (after the script name).
|
|
|
|
A. You are probably linking with GNU getopt, e.g. through -liberty.
|
|
Don't. The reason for the complaint is that GNU getopt, unlike System
|
|
V getopt and other getopt implementations, doesn't consider a
|
|
non-option to be the end of the option list. A quick (and compatible)
|
|
fix for scripts is to add "--" to the interpreter, like this:
|
|
|
|
#! /usr/local/bin/python --
|
|
|
|
You can also use this interactively:
|
|
|
|
python -- script.py [options]
|
|
|
|
Note that a working getopt implementation is provided in the Python
|
|
distribution (in Python/getopt.c) but not automatically used.
|
|
|
|
3.5. Q. When building on the SGI, make tries to run python to create
|
|
glmodule.c, but python hasn't been built or installed yet.
|
|
|
|
A. Comment out the line mentioning glmodule.c in Setup and build a
|
|
python without gl first; install it or make sure it is in your $PATH,
|
|
then edit the Setup file again to turn on the gl module, and make
|
|
again. You don't need to do "make clean"; you do need to run "make
|
|
Makefile" in the Modules subdirectory (or just run "make" at the
|
|
toplevel).
|
|
|
|
3.6. Q. Python built with gcc for the DEC Alpha doesn't work.
|
|
|
|
People have reported problems with gcc 2.5.8 up to 2.6.3. The DEC
|
|
OSF/1 cc compiler does not have these problems so it's likely a gcc
|
|
bug. The latest news is that this has been fixed in Python 1.2 by a
|
|
source change (I gave up waiting for a fixed gcc).
|
|
|
|
3.7. Q. I use VPATH but some targets are built in the source directory.
|
|
|
|
A. On some systems (e.g. Sun), if the target already exists in the
|
|
source directory, it is created there instead of in the build
|
|
directory. This is usually because you have previously built without
|
|
VPATH. Try running "make clobber" in the source directory.
|
|
|
|
3.8. Q. Trouble building or linking with the GNU readline library.
|
|
|
|
A. Consider using readline 2.0. Some hints:
|
|
|
|
- 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 and build the GNU
|
|
readline library before running the configure script. Its sources are
|
|
no longer 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). 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:
|
|
|
|
- On SGI IRIX 5, you may have to add the following
|
|
to rldefs.h:
|
|
|
|
#ifndef sigmask
|
|
#define sigmask(sig) (1L << ((sig)-1))
|
|
#endif
|
|
|
|
- On most systems, you will have to add #include "rldefs.h" to the
|
|
top of several source files, and if you use the VPATH feature, you
|
|
will have to add dependencies of the form foo.o: foo.c to the
|
|
Makefile for several values of foo.
|
|
|
|
- The readline library requires use of the termcap library. A
|
|
known problem with this is that it contains entry points which
|
|
cause conflicts with the STDWIN and SGI GL libraries. The STDWIN
|
|
conflict can be solved (and will be, in the next release of
|
|
STDWIN) by adding a line saying '#define werase w_erase' to the
|
|
stdwin.h file (in the STDWIN distribution, subdirectory H). The
|
|
GL conflict has been solved in the Python configure script by a
|
|
hack that forces use of the static version of the termcap library.
|
|
|
|
- Check the newsgroup gnu.bash.bug <URL:news:gnu.bash.bug> for
|
|
specific problems with the readline library (I don't read this group
|
|
but I've been told that it is the place for readline bugs).
|
|
|
|
3.9. Q. Trouble building Python on Linux.
|
|
|
|
A. If you're building Python 1.2, Slackware 2.2 has a buggy bash
|
|
(version 1.14.3) which breaks a sed script that is used to build
|
|
Modules/Makefile. Replace /bin/sh with /bin/ash in both makesetup and
|
|
Makefile.pre.in.
|
|
|
|
In 1.1 and 1.1.1, there's a bug in the reference counting logic of
|
|
ternary pow() which is only tripped by very picky mallocs, like the
|
|
GNU malloc on Linux. This has been fixed in 1.2. To continue the
|
|
tests in 1.1(.1), just disable the tests of pow() with three arguments
|
|
from Lib/test/test_b2.py.
|
|
|
|
Apart from this, Python builds and runs fine on most Linux versions
|
|
(if you run into trouble on an old Linux version, consider upgrading).
|
|
|
|
3.10. Q. Trouble with prototypes on Ultrix.
|
|
|
|
A. Ultrix cc seems broken -- use gcc, or edit config.h to #undef
|
|
HAVE_PROTOTYPES.
|
|
|
|
3.11. Q. Trouble with posix.listdir on NeXTSTEP 3.2.
|
|
|
|
A. (This often manifests itself as a weird error from the
|
|
compileall.py script run by "make libinstall".)
|
|
|
|
Don't use gcc, use the Next C compiler (cc). Even though it is
|
|
derived from (an old version of) gcc, its interpretation of the
|
|
"-posix" switch is different; in this particular case, cc is right and
|
|
gcc is wrong.
|
|
|
|
3.12. Q. Other trouble building Python on platform X.
|
|
|
|
A. Please email the details to <guido@cwi.nl> and I'll look into it.
|
|
Please provide as many details as possible. In particular, if you
|
|
don't tell me what type of computer and what operating system (and
|
|
version) you are using it will be difficult for me to figure out what
|
|
is the matter. If you get a specific error message, please email it
|
|
to me too.
|
|
|
|
3.13. Q. How to configure dynamic loading on Lixux.
|
|
|
|
A. There are two answers, depending on whether you are using the new
|
|
ELF object format or not.
|
|
|
|
For ELF, this seems to be the procedure (thanks to Martin von Loewis):
|
|
|
|
Compile Python to an ELF binary.
|
|
|
|
In addition, you have to use the following flags:
|
|
|
|
- when linking python: -rdynamic -ldl
|
|
- when compiling an object that goes into a shared module: -fPIC
|
|
- when linking a shared module: -shared -ldl
|
|
|
|
Furthermore, it appears that some Python releases did not understand
|
|
that Linux has dynamic linking. Python 1.2 did it right, but you
|
|
should check wether the generated config.h indicates the use of -ldl
|
|
(i.e. dlopen, dlsym). Finally, you can load a shared module by saying
|
|
'use foo'. Make sure the module is in your PYTHONPATH.
|
|
|
|
For pre-ELF systems (thanks to Andrew Kuchling):
|
|
|
|
Pre-ELF Linux requires that you use the GNU DLD library. The stages
|
|
of using dynamic libraries on Linux are:
|
|
|
|
1) Get dld 3.2.5 from a Linux site. Be careful here; the most
|
|
recent GNU version is 3.2.3, and doesn't support Linux; be sure to
|
|
get it from a Linux mirror, not a GNU mirror (3.2.4 should also
|
|
work). Compile it and install the library libdld.a somewhere; I
|
|
used /usr/local/lib.
|
|
|
|
Suitable URLs for the dld distribution are currently:
|
|
<URL:ftp://sunsite.unc.edu/pub/Linux/libs/dld-3.2.5.src.tar.gz> and
|
|
<URL:ftp://tsx-11.mit.edu/pub/linux/sources/libs/dld-3.2.5.src.tar.gz>.
|
|
There's also a binary distribution of it:
|
|
<URL:ftp://sunsite.unc.edu/pub/Linux/libs/dld-3.2.5.bin.tar.gz>.
|
|
|
|
2) Get Jack Jansen's DL library; its location is given in the
|
|
_Extending Python_ manual as <URL:ftp://ftp.cwi.nl/pub/dynload/>.
|
|
Compile it and install libdl.a wherever you put libdld.a.
|
|
|
|
3) Run Python's configure script, giving it the --with-dl-dld option,
|
|
which requires a parameter giving the directory where you put the
|
|
libraries.
|
|
|
|
4) Recompile Python.
|
|
|
|
3.14. Q. Under Solaris 2.x, using GCC, how do I use shared libraries?
|
|
|
|
A. Use the linker in /usr/ucb/ld, not the GNU linker. The latter
|
|
cannot create shared libraries.
|
|
|
|
3.15. Q. Errors when linking with a shared library containing C++ code.
|
|
|
|
A. Link the main Python binary with C++. Change the definition of
|
|
LINKCC in Modules/Makefile to be your C++ compiler. You may have to
|
|
edit config.c slightly to make it compilable with C++.
|
|
|
|
3.16. Q. Tk menus don't work properly in Python 1.2.
|
|
|
|
A. There's a bug in Tkinter.py; remove ClassType and InstanceType from
|
|
the definition of CallableTypes near the top of Lib/tkinter/Tkinter.py.
|
|
|
|
3.17. Q. I built with tkintermodule.c enabled but get "Tkinter not found".
|
|
|
|
A. Tkinter.py (note: upper case T) lives in a subdirectory of Lib,
|
|
Lib/tkinter. If you are using the default module search path, you
|
|
probably didn't enable the line in the Modules/Setup file defining
|
|
TKPATH; if you use the environment variable PYTHONPATH, you'll have to
|
|
add the proper tkinter subdirectory.
|
|
|
|
3.18. Q. I built with Tk 4.0 but Tkinter complains about the Tk version.
|
|
|
|
A. Several things could cause this. You most likely have a Tk 3.6
|
|
installation that wasn't completely eradicated by the Tk 4.0
|
|
installation (which tends to add "4.0" to its installed files). You
|
|
may have the Tk 3.6 support library installed in the place where the
|
|
Tk 4.0 support files should be (default /usr/local/lib/tk/); you may
|
|
have compiled Python with the old tk.h header file (yes, this actually
|
|
compiles!); you may actually have linked with Tk 3.6 even though Tk
|
|
4.0 is also around. Similar for Tcl 7.4 vs. Tcl 7.3.
|
|
|
|
3.19. Q. Tk doesn't work right on DEC Alpha.
|
|
|
|
A. You probably compiled either Tcl, Tk or Python with gcc. Don't.
|
|
For this platform, which has 64-bit integers, gcc is known to generate
|
|
broken code. The standard cc (which comes bundled with the OS!)
|
|
works. If you still prefer gcc, at least try recompiling with cc
|
|
before reporting problems to the newsgroup or the author; if this
|
|
fixes the problem, report the bug to the gcc developers instead. (As
|
|
far as we know, there are no problem with gcc on other platforms --
|
|
the instabilities seem to be restricted to the DEC Alpha.) See also
|
|
question 3.6.
|
|
|
|
|
|
4. Programming in Python
|
|
========================
|
|
|
|
4.1. Q. Is there a source code level debugger with breakpoints, step,
|
|
etc.?
|
|
|
|
A. Yes. Check out module pdb; pdb.help() prints the documentation (or
|
|
you can read it as Lib/pdb.doc). If you use the STDWIN option,
|
|
there's also a windowing interface, wdb. You can write your own
|
|
debugger by using the code for pdb or wdb as an example.
|
|
|
|
4.2. Q. Can I create an object class with some methods implemented in
|
|
C and others in Python (e.g. through inheritance)? (Also phrased as:
|
|
Can I use a built-in type as base class?)
|
|
|
|
A. No, but you can easily create a Python class which serves as a
|
|
wrapper around a built-in object, e.g. (for dictionaries):
|
|
|
|
# A user-defined class behaving almost identical
|
|
# to a built-in dictionary.
|
|
class UserDict:
|
|
def __init__(self): self.data = {}
|
|
def __repr__(self): return repr(self.data)
|
|
def __cmp__(self, dict):
|
|
if type(dict) == type(self.data):
|
|
return cmp(self.data, dict)
|
|
else:
|
|
return cmp(self.data, dict.data)
|
|
def __len__(self): return len(self.data)
|
|
def __getitem__(self, key): return self.data[key]
|
|
def __setitem__(self, key, item): self.data[key] = item
|
|
def __delitem__(self, key): del self.data[key]
|
|
def keys(self): return self.data.keys()
|
|
def items(self): return self.data.items()
|
|
def values(self): return self.data.values()
|
|
def has_key(self, key): return self.data.has_key(key)
|
|
|
|
4.3. Q. Is there a curses/termcap package for Python?
|
|
|
|
A. Yes -- Lance Ellinghaus has written a module that interfaces to
|
|
System V's "ncurses". If you know a little curses and some Python,
|
|
it's straightforward to use. It is part of the standard Python
|
|
distribution, but not configured by default -- you must enable it by
|
|
editing Modules/Setup. It requires a System V curses implementation.
|
|
|
|
You could also consider using the "alfa" (== character cell) version
|
|
of STDWIN. (Standard Window System Interface, a portable windowing
|
|
system interface by myself <URL:ftp://ftp.cwi.nl/pub/stdwin/>.) This
|
|
will also prepare your program for porting to windowing environments
|
|
such as X11 or the Macintosh.
|
|
|
|
4.4. Q. Is there an equivalent to C's onexit() in Python?
|
|
|
|
A. Yes, if you import sys and assign a function to sys.exitfunc, it
|
|
will be called when your program exits, is killed by an unhandled
|
|
exception, or (on UNIX) receives a SIGHUP or SIGTERM signal.
|
|
|
|
4.5. Q. When I define a function nested inside another function, the
|
|
nested function seemingly can't access the local variables of the
|
|
outer function. What is going on? How do I pass local data to a
|
|
nested function?
|
|
|
|
A. Python does not have arbitrarily nested scopes. When you need to
|
|
create a function that needs to access some data which you have
|
|
available locally, create a new class to hold the data and return a
|
|
method of an instance of that class, e.g.:
|
|
|
|
class MultiplierClass:
|
|
def __init__(self, factor):
|
|
self.factor = factor
|
|
def multiplier(self, argument):
|
|
return argument * self.factor
|
|
|
|
def generate_multiplier(factor):
|
|
return MultiplierClass(factor).multiplier
|
|
|
|
twice = generate_multiplier(2)
|
|
print twice(10)
|
|
# Output: 20
|
|
|
|
An alternative solution uses default arguments, e.g.:
|
|
|
|
def generate_multiplier(factor):
|
|
def multiplier(arg, fact = factor):
|
|
return arg*fact
|
|
return multiplier
|
|
|
|
twice = generate_multiplier(2)
|
|
print twice(10)
|
|
# Output: 20
|
|
|
|
4.6. Q. How do I iterate over a sequence in reverse order?
|
|
|
|
A. If it is a list, the fastest solution is
|
|
|
|
list.reverse()
|
|
try:
|
|
for x in list:
|
|
"do something with x"
|
|
finally:
|
|
list.reverse()
|
|
|
|
This has the disadvantage that while you are in the loop, the list
|
|
is temporarily reversed. If you don't like this, you can make a copy.
|
|
This appears expensive but is actually faster than other solutions:
|
|
|
|
rev = list[:]
|
|
rev.reverse()
|
|
for x in rev:
|
|
<do something with x>
|
|
|
|
If it isn't a list, a more general but slower solution is:
|
|
|
|
i = len(list)
|
|
while i > 0:
|
|
i = i-1
|
|
x = list[i]
|
|
<do something with x>
|
|
|
|
A more elegant solution, is to define a class which acts as a sequence
|
|
and yields the elements in reverse order (solution due to Steve
|
|
Majewski):
|
|
|
|
class Rev:
|
|
def __init__(self, seq):
|
|
self.forw = seq
|
|
def __len__(self):
|
|
return len(self.forw)
|
|
def __getitem__(self, i):
|
|
return self.forw[-(i + 1)]
|
|
|
|
You can now simply write:
|
|
|
|
for x in Rev(list):
|
|
<do something with x>
|
|
|
|
Unfortunately, this solution is slowest of all, due to the method
|
|
call overhead...
|
|
|
|
4.7. Q. My program is too slow. How do I speed it up?
|
|
|
|
A. That's a tough one, in general. There are many tricks to speed up
|
|
Python code; I would consider rewriting parts in C only as a last
|
|
resort. One thing to notice is that function and (especially) method
|
|
calls are rather expensive; if you have designed a purely OO interface
|
|
with lots of tiny functions that don't do much more than get or set an
|
|
instance variable or call another method, you may consider using a
|
|
more direct way, e.g. directly accessing instance variables. Also see
|
|
the standard module "profile" (described in the file
|
|
"python/lib/profile.doc") which makes it possible to find out where
|
|
your program is spending most of its time (if you have some patience
|
|
-- the profiling itself can slow your program down by an order of
|
|
magnitude).
|
|
|
|
4.8. Q. When I have imported a module, then edit it, and import it
|
|
again (into the same Python process), the changes don't seem to take
|
|
place. What is going on?
|
|
|
|
A. For reasons of efficiency as well as consistency, Python only reads
|
|
the module file on the first time a module is imported. (Otherwise a
|
|
program consisting of many modules, each of which imports the same
|
|
basic module, would read the basic module over and over again.) To
|
|
force rereading of a changed module, do this:
|
|
|
|
import modname
|
|
reload(modname)
|
|
|
|
Warning: this technique is not 100% fool-proof. In particular,
|
|
modules containing statements like
|
|
|
|
from modname import some_objects
|
|
|
|
will continue to work with the old version of the imported objects.
|
|
|
|
4.9. Q. How do I find the current module name?
|
|
|
|
A. A module can find out its own module name by looking at the
|
|
(predefined) global variable __name__. If this has the value
|
|
'__main__' you are running as a script.
|
|
|
|
4.10. Q. I have a module in which I want to execute some extra code
|
|
when it is run as a script. How do I find out whether I am running as
|
|
a script?
|
|
|
|
A. See the previous question. E.g. if you put the following on the
|
|
last line of your module, main() is called only when your module is
|
|
running as a script:
|
|
|
|
if __name__ == '__main__': main()
|
|
|
|
4.11. Q. I try to run a program from the Demo directory but it fails
|
|
with ImportError: No module named ...; what gives?
|
|
|
|
A. This is probably an optional module (written in C!) which hasn't
|
|
been configured on your system. This especially happens with modules
|
|
like "Tkinter", "stdwin", "gl", "Xt" or "Xm". For Tkinter, STDWIN and
|
|
many other modules, see Modules/Setup.in for info on how to add these
|
|
modules to your Python, if it is possible at all. Sometimes you will
|
|
have to ftp and build another package first (e.g. STDWIN). Sometimes
|
|
the module only works on specific platforms (e.g. gl only works on SGI
|
|
machines).
|
|
|
|
NOTE: if the complaint is about "Tkinter" (upper case T) and you have
|
|
already configured module "tkinter" (lower case t), the solution is
|
|
*not* to rename tkinter to Tkinter or vice versa. There is probably
|
|
something wrong with your module search path. Check out the value of
|
|
sys.path.
|
|
|
|
For X-related modules (Xt and Xm) you will have to do more work: they
|
|
are currently not part of the standard Python distribution. You will
|
|
have to ftp the Extensions tar file, e.g.
|
|
<URL:ftp://ftp.python.org/pub/python/src/extensions.tar.gz> and follow
|
|
the instructions there.
|
|
|
|
See also the next question.
|
|
|
|
4.12. Q. I have successfully built Python with STDWIN but it can't
|
|
find some modules (e.g. stdwinevents).
|
|
|
|
A. There's a subdirectory of the library directory named 'stdwin'
|
|
which should be in the default module search path. There's a line in
|
|
Modules/Setup(.in) that you have to enable for this purpose --
|
|
unfortunately in the latest release it's not near the other
|
|
STDWIN-related lines so it's easy to miss it.
|
|
|
|
4.13. Q. What GUI toolkits exist for Python?
|
|
|
|
A. Depending on what platform(s) you are aiming at, there are several.
|
|
|
|
- There's a neat object-oriented interface to the Tcl/Tk widget set,
|
|
called Tkinter. As of python 1.1, it is part of the standard Python
|
|
distribution -- all you need to do is enable it in Modules/Setup
|
|
(provided you have already installed Tk and Tcl). This is probably
|
|
the easiest to install and use, and the most complete widget set. It
|
|
is also very likely that in the future the standard Python GUI API
|
|
will be based on or at least look very much like the Tkinter
|
|
interface. For more info about Tk, including pointers to the source,
|
|
see the Tcl/Tk home page <URL:http://www.sunlabs.com/research/tcl/>.
|
|
|
|
- The standard Python distribution comes with an interface to STDWIN,
|
|
a platform-independent low-level windowing interface. You have to ftp
|
|
the source for STDWIN separately,
|
|
e.g. <URL:ftp://ftp.cwi.nl/pub/stdwin/> or gatekeeper.dec.com in
|
|
pub/misc/stdwin <URL:ftp://gatekeeper.dec.com/pub/misc/stdwin/>.
|
|
STDWIN runs under X11 or the Mac; a Windows port has been attempted
|
|
but I can't seem to get it working. Note that STDWIN is really not
|
|
powerful enough to implement a modern GUI (no widgets, etc.) and that
|
|
I don't have the time to maintain or extend it, so you may be better
|
|
off using Tkinter or the Motif interface, unless you require
|
|
portability to the Mac (which is also offered by SUIT, by the way --
|
|
see below).
|
|
|
|
- For SGI IRIX only, there's an interface to the complete GL (Graphics
|
|
Library -- low level but very good 3D capabilities) as well as to
|
|
FORMS (a buttons-and-sliders-etc package built on top of GL by Mark
|
|
Overmars -- ftp'able from <URL:ftp://ftp.cs.ruu.nl/pub/SGI/FORMS/>).
|
|
|
|
- There's an interface to X11, including the Athena and Motif widget
|
|
sets (and a few individual widgets, like Mosaic's HTML widget and
|
|
SGI's GL widget) in the Extensions set, which is separately ftp'able
|
|
<URL:ftp://ftp.python.org/pub/python/src/extensions.tar.gz>.
|
|
|
|
- There's an interface to SUIT, the U of Virginia's Simple User
|
|
Interface Toolkit; it can be ftp'ed from
|
|
<URL:ftp://uvacs.cs.virginia.edu/pub/suit/python/SUIT_python.tar.Z>.
|
|
A PC binary of Python 1.0.2 compiled with DJGPP and with SUIT support
|
|
built-in has been made available by Antonio Costa
|
|
<URL:ftp://asterix.inescn.pt/pub/PC/python/pyt102su.exe> (a
|
|
self-extracting archive). Note that the UVa people themselves have
|
|
expressed doubts about SUIT, and are planning to build a Python GUI
|
|
API based upon Tk (though not necessarily on Tkinter); see
|
|
<URL:http://server.cs.virginia.edu/~tnb2d/IT/IT.html>.
|
|
|
|
- There's an interface to WAFE, a Tcl interface to the X11 Motif and
|
|
Athena widget sets. Last I heard about it it was included in the WAFE
|
|
1.0 prerelease
|
|
<URL:ftp://ftp.wu-wien.ac.at/pub/src/X11/wafe/wafe-1.0.tar.gz-prerelease>.
|
|
|
|
- The NT port by Mark Hammond (see question 7.4) includes an interface
|
|
to the Microsoft Foundation Classes and a Python programming
|
|
environment using it that's written mostly in Python. See
|
|
<URL:ftp://ftp.python.org/pub/python/nt/>.
|
|
|
|
- There's an interface to wxWindows. wxWindows is a portable GUI
|
|
class library written in C++. It supports XView, Motif, MS-Windows as
|
|
targets. There is some support for Macs and CURSES as well. wxWindows
|
|
preserves the look and feel of the underlying graphics toolkit. See
|
|
the wxPython WWW page at
|
|
<URL:http://www.aiai.ed.ac.uk/~jacs/wx/wxpython/wxpython.html>.
|
|
|
|
- There's an object-oriented GUI based on the Microsoft Foundation
|
|
Classes model called WPY. Programs written in WPY run unchanged and
|
|
with native look and feel on NT, Windows 3.1 (using win32s) and on
|
|
Unix (using Tk). Source and binaries for NT and Linux are available
|
|
in <URL:ftp://ftp.python.org/pub/python/wpy>.
|
|
|
|
- Python has been mentioned on the "Futurism" subpage of the Fresco
|
|
home page <URL:http://www.faslab.com/fresco/HomePage.html>. "Pesto"
|
|
is a Python interface to the CORBA dynamic invocation interface, and
|
|
thus Fresco. A Pesto prototype is running and is currently being
|
|
packaged up for inclusion in the Fresco snapshot. See also the Pesto
|
|
web pages: <URL:http://www.faslab.com/fresco/pesto/Index.html>.
|
|
|
|
4.14. Q. Are there any interfaces to database packages in Python?
|
|
|
|
A. There's an interface to SYBASE by John Redford
|
|
<jredford@lehman.com>.
|
|
|
|
There's an interface to metalbase by Lance Ellinghaus
|
|
<lance@markv.com>; it is part of the separate Extensions distribution
|
|
<URL:ftp://ftp.python.org/pub/python/src/extensions.tar.gz>.
|
|
|
|
Anthony Baxter <anthony.baxter@aaii.oz.au> has written an interface to
|
|
mSQL (mini-SQL).
|
|
<URL:ftp://ftp.python.org/pub/python/contrib/PymSQL.tar.gz>.
|
|
|
|
Tom Culliton <culliton@clark.net> has written an Oracle module.
|
|
See <URL:ftp://ftp.clark.net/pub/culliton/oramod.tgz>.
|
|
|
|
4.15. Q. Is it possible to write obfuscated one-liners in Python?
|
|
|
|
A. Yes. See the following three examples, due to Ulf Bartelt:
|
|
|
|
# Primes < 1000
|
|
print filter(None,map(lambda y:y*reduce(lambda x,y:x*y!=0,
|
|
map(lambda x,y=y:y%x,range(2,int(pow(y,0.5)+1))),1),range(2,1000)))
|
|
|
|
# First 10 Fibonacci numbers
|
|
print map(lambda x,f=lambda x,f:(x<=1) or (f(x-1,f)+f(x-2,f)): f(x,f),
|
|
range(10))
|
|
|
|
# Mandelbrot set
|
|
print (lambda Ru,Ro,Iu,Io,IM,Sx,Sy:reduce(lambda x,y:x+y,map(lambda y,
|
|
Iu=Iu,Io=Io,Ru=Ru,Ro=Ro,Sy=Sy,L=lambda yc,Iu=Iu,Io=Io,Ru=Ru,Ro=Ro,i=IM,
|
|
Sx=Sx,Sy=Sy:reduce(lambda x,y:x+y,map(lambda x,xc=Ru,yc=yc,Ru=Ru,Ro=Ro,
|
|
i=i,Sx=Sx,F=lambda xc,yc,x,y,k,f=lambda xc,yc,x,y,k,f:(k<=0)or (x*x+y*y
|
|
>=4.0) or 1+f(xc,yc,x*x-y*y+xc,2.0*x*y+yc,k-1,f):f(xc,yc,x,y,k,f):chr(
|
|
64+F(Ru+x*(Ro-Ru)/Sx,yc,0,0,i)),range(Sx))):L(Iu+y*(Io-Iu)/Sy),range(Sy
|
|
))))(-2.1, 0.7, -1.2, 1.2, 30, 80, 24)
|
|
# \___ ___/ \___ ___/ | | |__ lines on screen
|
|
# V V | |______ columns on screen
|
|
# | | |__________ maximum of "iterations"
|
|
# | |_________________ range on y axis
|
|
# |____________________________ range on x axis
|
|
|
|
Don't try this at home, kids!
|
|
|
|
4.16. Q. Is there an equivalent of C's "?:" ternary operator?
|
|
|
|
A. Not directly. In many cases you can mimic a?b:c with "a and b or
|
|
c", but there's a flaw: if b is zero (or empty, or None -- anything
|
|
that tests false) then c will be selected instead. In many cases you
|
|
can prove by looking at the code that this can't happen (e.g. because
|
|
b is a constant or has a type that can never be false), but in general
|
|
this can be a problem.
|
|
|
|
Steve Majewski (or was it Tim Peters?) suggested the following
|
|
solution: (a and [b] or [c])[0]. Because [b] is a singleton list it
|
|
is never false, so the wrong path is never taken; then applying [0] to
|
|
the whole thing gets the b or c that you really wanted. Ugly, but it
|
|
gets you there in the rare cases where it is really inconvenient to
|
|
rewrite your code using 'if'.
|
|
|
|
4.17. Q. My class defines __del__ but it is not called when I delete the
|
|
object.
|
|
|
|
A. There are several possible reasons for this.
|
|
|
|
- The del statement does not necessarily call __del__ -- it simply
|
|
decrements the object's reference count, and if this reaches zero
|
|
__del__ is called.
|
|
|
|
- If your data structures contain circular links (e.g. a tree where
|
|
each child has a parent pointer and each parent has a list of
|
|
children) the reference counts will never go back to zero. You'll
|
|
have to define an explicit close() method which removes those
|
|
pointers. Please don't ever call __del__ directly -- __del__ should
|
|
call close() and close() should make sure that it can be called more
|
|
than once for the same object.
|
|
|
|
- If the object has ever been a local variable (or argument, which is
|
|
really the same thing) to a function that caught an expression in an
|
|
except clause, chances are that a reference to the object still exists
|
|
in that function's stack frame as contained in the stack trace.
|
|
Normally, deleting (better: assigning None to) sys.exc_traceback will
|
|
take care of this. If you a stack was printed for an unhandled
|
|
exception in an interactive interpreter, delete sys.last_traceback
|
|
instead.
|
|
|
|
- There is code that deletes all objects when the interpreter exits,
|
|
but if your Python has been configured to support threads, it is not
|
|
called (because other threads may still be active). You can define
|
|
your own cleanup function using sys.exitfunc (see question 4.4).
|
|
|
|
- Finally, there are some obscure bugs if your __del__ method does
|
|
complicated things such as updating dictionaries or lists or
|
|
references globals. I hope to have fixed these in release 1.2.
|
|
|
|
4.18. Q. How do I change the shell environment for programs called
|
|
using os.popen() or os.system()? Changing os.environ doesn't work.
|
|
|
|
A. Modifying the environment passed to subshells was left out of the
|
|
interpreter because there seemed to be no well-established portable
|
|
way to do it (in particular, some systems, have putenv(), others have
|
|
setenv(), and some have none at all).
|
|
|
|
However if all you want is to pass environment variables to the
|
|
commands run by os.system() or os.popen(), there's a simple solution:
|
|
prefix the command string with a couple of variable assignments and
|
|
export statements. The following would be universal for popen:
|
|
|
|
import os
|
|
from commands import mkarg # nifty routine to add shell quoting
|
|
def epopen(cmd, mode, env = {}):
|
|
# env is a dictionary of environment variables
|
|
prefix = ''
|
|
for key, value in env.items():
|
|
prefix = prefix + '%s=%s\n' % (key, mkarg(value)[1:])
|
|
prefix = prefix + 'export %s\n' % key
|
|
return os.popen(prefix + cmd, mode)
|
|
|
|
4.19. Q. What is a class?
|
|
|
|
A. A class is the particular object type that is created by executing
|
|
a class statement. Class objects are used as templates, to create
|
|
class instance objects, which embody both the data structure and
|
|
program routines specific to a datatype.
|
|
|
|
4.20. Q. What is a method?
|
|
|
|
A. A method is a function that you normally call as
|
|
x.name(arguments...) for some object x. The term is used for methods
|
|
of classes and class instances as well as for methods of built-in
|
|
objects. (The latter have a completely different implementation and
|
|
only share the way their calls look in Python code.) Methods of
|
|
classes (and class instances) are defined as functions inside the
|
|
class definition.
|
|
|
|
4.21. Q. What is self?
|
|
|
|
A. Self is merely a conventional name for the first argument of a
|
|
method -- i.e. a function defined inside a class definition. A method
|
|
defined as meth(self, a, b, c) should be called as x.meth(a, b, c) for
|
|
some instance x of the class in which the definition occurs;
|
|
the called method will think it is called as meth(x, a, b, c).
|
|
|
|
4.22. Q. What is a unbound method?
|
|
|
|
A. An unbound method is a method defined in a class that is not yet
|
|
bound to an instance. You get an unbound method if you ask for a
|
|
class attribute that happens to be a function. You get a bound method
|
|
if you ask for an instance attribute. A bound method knows which
|
|
instance it belongs to and calling it supplies the instance automatically;
|
|
an unbound method only knows which class it wants for its first
|
|
argument (a derived class is also OK). Calling an unbound method
|
|
doesn't "magically" derive the first argument from the context -- you
|
|
have to provide it explicitly.
|
|
|
|
4.23. Q. How do I call a method defined in a base class from a derived
|
|
class that overrides it?
|
|
|
|
A. If your class definition starts with "class Derived(Base): ..."
|
|
then you can call method meth defined in Base (or one of Base's base
|
|
classes) as Base.meth(self, arguments...). Here, Base.meth is an
|
|
unbound method (see previous question).
|
|
|
|
4.24. Q. How do I call a method from a base class without using the
|
|
name of the base class?
|
|
|
|
A. DON'T DO THIS. REALLY. I MEAN IT. It appears that you could call
|
|
self.__class__.__bases__[0].meth(self, arguments...) but this fails when
|
|
a doubly-derived method is derived from your class: for its instances,
|
|
self.__class__.__bases__[0] is your class, not its base class -- so
|
|
(assuming you are doing this from within Derived.meth) you would start
|
|
a recursive call.
|
|
|
|
4.25. Q. How can I organize my code to make it easier to change the base
|
|
class?
|
|
|
|
A. You could define an alias for the base class, assign the real base
|
|
class to it before your class definition, and use the alias throughout
|
|
your class. Then all you have to change is the value assigned to the
|
|
alias. Incidentally, this trick is also handy if you want to decide
|
|
dynamically (e.g. depending on availability of resources) which base
|
|
class to use. Example:
|
|
|
|
BaseAlias = <real base class>
|
|
class Derived(BaseAlias):
|
|
def meth(self):
|
|
BaseAlias.meth(self)
|
|
...
|
|
|
|
4.26. Q. How can I find the methods or attributes of an object?
|
|
|
|
A. This depends on the object type.
|
|
|
|
For an instance x of a user-defined class, instance attributes are
|
|
found in the dictionary x.__dict__, and methods and attributes defined
|
|
by its class are found in x.__class__.__bases__[i].__dict__ (for i in
|
|
range(len(x.__class__.__bases__))). You'll have to walk the tree of
|
|
base classes to find *all* class methods and attributes.
|
|
|
|
Many, but not all built-in types define a list of their method names
|
|
in x.__methods__, and if they have data attributes, their names may be
|
|
found in x.__members__. However this is only a convention.
|
|
|
|
For more information, read the source of the standard (but
|
|
undocumented) module newdir.
|
|
|
|
4.27. Q. I can't seem to use os.read() on a pipe created with os.popen().
|
|
|
|
A. os.read() is a low-level function which takes a file descriptor (a
|
|
small integer). os.popen() creates a high-level file object -- the
|
|
same type used for sys.std{in,out,err} and returned by the builtin
|
|
open() function. Thus, to read n bytes from a pipe p created with
|
|
os.popen(), you need to use p.read(n).
|
|
|
|
4.28. Q. How can I create a stand-alone binary from a Python script?
|
|
|
|
The demo script "Demo/scripts/freeze.py" does what you want. (It's
|
|
actually not a demo but a support tool -- there is some extra code in
|
|
the interpreter to accommodate it.) It requires that you have the
|
|
Python build tree handy, complete with all the lib*.a files.
|
|
|
|
This works by scanning your source recursively for import statements
|
|
(both forms) and looking for the modules on the standard Python path
|
|
as well as in the source directory (for built-in modules). It then
|
|
"compiles" the modules written in Python to C code (array initializers
|
|
that can be turned into code objects using the marshal module) and
|
|
creates a custom-made config file that only contains those built-in
|
|
modules which are actually used in the program. It then compiles the
|
|
generated C code and links it with the rest of the Python interpreter
|
|
to form a self-contained binary which acts exactly like your script.
|
|
|
|
Hint: the freeze program only works if your script's filename ends in
|
|
".py".
|
|
|
|
4.29. Q. What WWW tools are there for Python?
|
|
|
|
A. There's a whole lot in the 1.2 release; see the section on
|
|
"Internet and WWW" in the Library Reference Manual. Highlights: a CGI
|
|
parser, a url retriever, an html parser.
|
|
|
|
Steve Miale <smiale@cs.indiana.edu> has written a modular WWW browser
|
|
called Dancer. An alpha version can be FTP'ed from
|
|
<URL:ftp://ftp.cs.indiana.edu/pub/smiale/dancer.tar.gz>. (There are a
|
|
few articles about Dancer in the (hyper)mail archive
|
|
<URL:http://www.cwi.nl/~guido/hypermail/python-1994q3/index.html>.)
|
|
|
|
4.30. Q. How do I run a subprocess with pipes connected to both input
|
|
and output?
|
|
|
|
A. This is really a UNIX question. Also, in general, it is unwise to
|
|
do so, because you can easily cause a deadlock where the parent
|
|
process is blocked waiting for output from the child, while the child
|
|
is blocked waiting for input from the child. This can be caused
|
|
because the parent expects the child to output more text than it does,
|
|
or it can be caused by data being stuck in stdio buffers due to lack
|
|
of flushing. The Python parent can of course explicitly flush the data
|
|
it sends to the child before it reads any output, but if the child is
|
|
a naive C program it can easily have been written to never explicitly
|
|
flush its output, even if it is interactive, since flushing is
|
|
normally automatic.
|
|
|
|
In many cases, all you really need is to run some data through a
|
|
command and get the result back. Unless the data is infinite in size,
|
|
the easiest (and often the most efficient!) way to do this is to write
|
|
it to a temporary file and run the command with that temporary file as
|
|
input. The standard module tempfile exports a function mktemp() which
|
|
generates unique temporary file names.
|
|
|
|
If after reading all of the above you still want to connect two pipes
|
|
to a subprocess's standard input and output, here's a simple solution,
|
|
due to Jack Jansen:
|
|
|
|
import os
|
|
import sys
|
|
import string
|
|
|
|
MAXFD = 100 # Max number of file descriptors in this system
|
|
|
|
def popen2(cmd):
|
|
cmd = string.split(cmd)
|
|
p2cread, p2cwrite = os.pipe()
|
|
c2pread, c2pwrite = os.pipe()
|
|
pid = os.fork()
|
|
if pid == 0:
|
|
# Child
|
|
os.close(0)
|
|
os.close(1)
|
|
if os.dup(p2cread) <> 0:
|
|
sys.stderr.write('popen2: bad read dup\n')
|
|
if os.dup(c2pwrite) <> 1:
|
|
sys.stderr.write('popen2: bad write dup\n')
|
|
for i in range(3, MAXFD):
|
|
try:
|
|
os.close(i)
|
|
except:
|
|
pass
|
|
try:
|
|
os.execv(cmd[0], cmd)
|
|
finally:
|
|
os._exit(1)
|
|
os.close(p2cread)
|
|
tochild = os.fdopen(p2cwrite, 'w')
|
|
os.close(c2pwrite)
|
|
fromchild = os.fdopen(c2pread, 'r')
|
|
return fromchild, tochild
|
|
|
|
Note that many interactive programs (e.g. vi) don't work well with
|
|
pipes substituted for standard input and output. You will have to use
|
|
pseudo ttys ("ptys") instead of pipes. There is some undocumented
|
|
code to use these in the library module pty.py -- I'm afraid you're on
|
|
your own here.
|
|
|
|
A different answer is a Python interface to Don Libes' "expect"
|
|
library. A prerelease of this is available on the Python ftp mirror
|
|
sites in the contrib subdirectory as expy-0.3.tar.gz, e.g.
|
|
<URL:ftp://ftp.python.org/pub/python/contrib/expy-0.3.tar.gz>.
|
|
|
|
4.31. Q. How do I call a function if I have the arguments in a tuple?
|
|
|
|
A. Use the built-in function apply(). For instance,
|
|
|
|
func(1, 2, 3)
|
|
|
|
is equivalent to
|
|
|
|
args = (1, 2, 3)
|
|
apply(func, args)
|
|
|
|
Note that func(args) is not the same -- it calls func() with exactly
|
|
one argument, the tuple args, instead of three arguments, the integers
|
|
1, 2 and 3.
|
|
|
|
4.32. Q. How do I enable font-lock-mode for Python in Emacs?
|
|
|
|
A. Assuming you're already using python-mode and font-lock-mode
|
|
separately, all you need to do is put this 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)
|
|
|
|
4.33. Q. Is there an inverse to the format operator (a la C's scanf())?
|
|
|
|
A. Not as such.
|
|
|
|
For simple input parsing, the easiest approach is usually to split
|
|
the line into whitespace-delimited words using string.split(), and to
|
|
convert decimal strings to numeric values using string.atoi(),
|
|
string.atol() or string.atof(). (Python's atoi() is 32-bit and its
|
|
atol() is arbitrary precision.) If you want to use another delimiter
|
|
than whitespace, use string.splitfield() (possibly combining it with
|
|
string.strip() which removes surrounding whitespace from a string).
|
|
|
|
For more complicated input parsing, regular expressions (see module
|
|
regex) are better suited and more powerful than C's scanf().
|
|
|
|
|
|
5. Extending Python
|
|
===================
|
|
|
|
5.1. Q. Can I create my own functions in C?
|
|
|
|
A. Yes, you can create built-in modules containing functions,
|
|
variables, exceptions and even new types in C. This is explained in
|
|
the document "Extending and Embedding the Python Interpreter" (the
|
|
LaTeX file Doc/ext.tex). Also read the chapter on dynamic loading.
|
|
|
|
5.2. Q. Can I create my own functions in C++?
|
|
|
|
A. Yes, using the C-compatibility features found in C++. Basically
|
|
you place extern "C" { ... } around the Python include files and put
|
|
extern "C" before each function that is going to be called by the
|
|
Python interpreter. Global or static C++ objects with constructors
|
|
are probably not a good idea.
|
|
|
|
5.3. Q. How can I execute arbitrary Python statements from C?
|
|
|
|
A. The highest-level function to do this is run_command() which takes
|
|
a single string argument which is executed in the context of module
|
|
__main__ and returns 0 for success and -1 when an exception occurred
|
|
(including SyntaxError). If you want more control, use run_string();
|
|
see the source for run_command() in Python/pythonrun.c.
|
|
|
|
5.4. Q. How can I evaluate an arbitrary Python expression from C?
|
|
|
|
A. Call the function run_string() from the previous question with the
|
|
start symbol eval_input; it then parses an expression, evaluates it
|
|
and returns its value. See exec_eval() in Python/bltinmodule.c.
|
|
|
|
5.5. Q. How do I extract C values from a Python object?
|
|
|
|
A. That depends on the object's type. If it's a tuple,
|
|
gettuplesize(o) returns its length and gettupleitem(o, i) returns its
|
|
i'th item; similar for lists with getlistsize(o) and getlistitem(o,
|
|
i). For strings, getstringsize(o) returns its length and
|
|
getstringvalue(o) a pointer to its value (note that Python strings may
|
|
contain null bytes so strlen() is not safe). To test which type an
|
|
object is, first make sure it isn't NULL, and then use
|
|
is_stringobject(o), is_tupleobject(o), is_listobject(o) etc.
|
|
|
|
5.6. Q. How do I use mkvalue() to create a tuple of arbitrary length?
|
|
|
|
A. You can't. Use t = newtupleobject(n) instead, and fill it with
|
|
objects using settupleitem(t, i, o) -- note that this "eats" a
|
|
reference count of o. Similar for lists with newlistobject(n) and
|
|
setlistitem(l, i, o). Note that you *must* set all the tuple items to
|
|
some value before you pass the tuple to Python code --
|
|
newtupleobject(n) initializes them to NULL, which isn't a valid Python
|
|
value.
|
|
|
|
5.7. Q. What happened to mktuple(), featured in an example in the
|
|
Extensions manual?
|
|
|
|
A. It's a typo, I meant newtupleobject() (see previous question).
|
|
|
|
5.8. Q. How do I call an object's method from C?
|
|
|
|
A. Here's a function (untested) that might become part of the next
|
|
release in some form. It uses <stdarg.h> to allow passing the
|
|
argument list on to vmkvalue():
|
|
|
|
object *call_method(object *inst, char *methodname, char *format, ...)
|
|
{
|
|
object *method;
|
|
object *args;
|
|
object *result;
|
|
va_list va;
|
|
method = getattr(inst, methodname);
|
|
if (method == NULL) return NULL;
|
|
va_start(va, format);
|
|
args = vmkvalue(format, va);
|
|
va_end(va);
|
|
if (args == NULL) {
|
|
DECREF(method);
|
|
return NULL;
|
|
}
|
|
result = call_object(method, args);
|
|
DECREF(method);
|
|
DECREF(args);
|
|
return result;
|
|
}
|
|
|
|
This works for any instance that has methods -- whether built-in or
|
|
user-defined. You are responsible for eventually DECREF'ing the
|
|
return value.
|
|
|
|
To call, e.g., a file object's "seek" method with arguments 10, 0
|
|
(assuming the file object pointer is "f"):
|
|
|
|
res = call_method(f, "seek", "(OO)", 10, 0);
|
|
if (res == NULL) {
|
|
... an exception occurred ...
|
|
}
|
|
else {
|
|
DECREF(res);
|
|
}
|
|
|
|
Note that since call_object() *always* wants a tuple for the argument
|
|
list, to call a function without arguments, pass "()" for the format,
|
|
and to call a function with one argument, surround the argument in
|
|
parentheses, e.g. "(i)".
|
|
|
|
5.9. Q. How do I catch the output from print_error()?
|
|
|
|
A. (Due to Mark Hammond):
|
|
|
|
* in Python code, define an object that supports the "write()" method.
|
|
FWIW, there seems to be a small problem that requires the 'softspace'
|
|
attribute to be defined too (fixed in 1.2).
|
|
|
|
* redirect sys.stdout and sys.stderr to this object.
|
|
|
|
* call print_error, or just allow the standard traceback mechanism to
|
|
work.
|
|
|
|
Then, the output will go wherever your write() method sends it.
|
|
|
|
5.10. Q. How do I access a module written in Python from C?
|
|
|
|
A. You can get a pointer to the module object as follows:
|
|
|
|
module = import_module("<modulename>");
|
|
|
|
If the module hasn't been imported yet (i.e. it is not yet present in
|
|
sys.modules), this initializes the module; otherwise it simply returns
|
|
the value of sys.modules["<modulename>"]. Note that it doesn't enter
|
|
the module into any namespace -- it only ensures it has been
|
|
initialized and is stored in sys.modules.
|
|
|
|
You can then access the module's attributes (i.e. any name defined in
|
|
the module) as follows:
|
|
|
|
attr = getattr(module, "<attrname>");
|
|
|
|
Calling setattr(), to assign to variables in the module, also works.
|
|
|
|
5.11. Q. How do I interface to C++ objects from Python?
|
|
|
|
A. Depending on your requirements, there are many approaches. Begin
|
|
by reading the "Extending and Embedding" document (Doc/ext.tex, see
|
|
also <URL:http://www.python.org/doc/>). Realize that for the Python
|
|
run-time system, there isn't a whole lot of difference between C and
|
|
C++ -- so the strategy to build a new Python type around a C structure
|
|
(pointer) type will also work for C++ objects.
|
|
|
|
Automatic generation of interfaces between Python and C++ is still at
|
|
the horizon -- parsing C++ header files requires an almost complete
|
|
C++ parser, and many features aren't easily translated from C++ to
|
|
Python: certain forms of operator oveloading, function overloading
|
|
(best approached by a varargs function which explicitly type-checks
|
|
its arguments), and reference arguments are just a number of features
|
|
that are hard to translate correctly if at all.
|
|
|
|
The hardest problem is to transparently translate the C++ class
|
|
hierarchy to Python, so that Python programs derive classes from C++
|
|
classes. Given suitable constraints, this may be possible, but it
|
|
would require more space than I have in this FAQ to explain how.
|
|
In any case, you can get quite a bit done without this, using just the
|
|
existing classes from Python.
|
|
|
|
If this all seems rather daunting, that may be because it is -- C++
|
|
isn't exactly a baby to handle without gloves! However, people have
|
|
accomplished amazing feats of interfacing between Python and C++, and
|
|
a detailed question posted to the Python list is likely to elicit some
|
|
interesting and useful responses.
|
|
|
|
|
|
6. Python's design
|
|
==================
|
|
|
|
6.1. Q. Why isn't there a generic copying operation for objects in Python?
|
|
|
|
A. Historically, there wasn't. However, starting in Python 1.2,
|
|
there's a library module "copy" which supports both shallow and deep
|
|
copying of most common Python objects (though not things like open
|
|
files, sockets or windows), including an extensible mechanism to copy
|
|
class instances.
|
|
|
|
6.2. Q. Why isn't there a generic way to implement persistent objects
|
|
in Python? (Persistent == automatically saved to and restored from
|
|
disk.)
|
|
|
|
A. Like the previous question, historically, there wasn't. The
|
|
library module "pickle" now solves this in a very general way (though
|
|
you still can't store things like open files, sockests or windows),
|
|
and the library module "shelve" uses pickle and (g)dbm to create
|
|
presistent mappings containing arbitrary Python objects. There are
|
|
some problems with shelve when using gdbm which will be solved in
|
|
Python 1.3.
|
|
|
|
6.3. Q. Why isn't there a switch or case statement in Python?
|
|
|
|
A. You can do this easily enough with a sequence of
|
|
if... elif... elif... else. There have been some proposals for switch
|
|
statement syntax, but there is no consensus (yet) on whether and how
|
|
to do range tests.
|
|
|
|
6.4. Q. Why does Python use indentation for grouping of statements?
|
|
|
|
A. Basically I believe that using indentation for grouping is
|
|
extremely elegant and contributes a lot to the clarity of the average
|
|
Python program. Most people learn to love this feature after a while.
|
|
Some arguments for it:
|
|
|
|
- Since there are no begin/end brackets there cannot be a disagreement
|
|
between grouping perceived by the parser and the human reader. I
|
|
remember long ago seeing a C fragment like this:
|
|
|
|
if (x <= y)
|
|
x++;
|
|
y--;
|
|
z++;
|
|
|
|
and staring a long time at it wondering why y was being decremented
|
|
even for x > y... (And I wasn't a C newbie then either.)
|
|
|
|
- Since there are no begin/end brackets, Python is much less prone to
|
|
coding-style conflicts. In C there are loads of different ways to
|
|
place the braces (including the choice whether to place braces around
|
|
single statements in certain cases, for consistency). If you're used
|
|
to reading (and writing) code that uses one style, you will feel at
|
|
least slightly uneasy when reading (or being required to write)
|
|
another style.
|
|
|
|
- Many coding styles place begin/end brackets on a line by themself.
|
|
This makes programs considerably longer and wastes valuable screen
|
|
space, making it harder to get a good overview over a program.
|
|
Ideally, a function should fit on one basic tty screen (say, 20
|
|
lines). 20 lines of Python are worth a LOT more than 20 lines of C.
|
|
This is not solely due to the lack of begin/end brackets (the lack of
|
|
declarations also helps, and the powerful operations of course), but
|
|
it certainly helps!
|
|
|
|
6.5. Q. Why are Python strings immutable?
|
|
|
|
A. There are two advantages. One is performance: knowing that a
|
|
string is immutable makes it easy to lay it out at construction time
|
|
-- fixed and unchanging storage requirements. (This is also one of
|
|
the reasons for the distinction between tuples and lists.) The
|
|
other is that strings in Python are considered as "elemental" as
|
|
numbers. No amount of activity will change the value 8 to anything
|
|
else, and in Python, no amount of activity will change the string
|
|
"eight" to anything else. (Adapted from Jim Roskind)
|
|
|
|
6.6. Q. Why don't strings have methods like index() or sort(), like
|
|
lists?
|
|
|
|
A. Good question. Strings currently don't have methods at all
|
|
(likewise tuples and numbers). Long ago, it seemed unnecessary to
|
|
implement any of these functions in C, so a standard library module
|
|
"string" written in Python was created that performs string related
|
|
operations. Since then, the cry for performance has moved most of
|
|
them into the built-in module strop (this is imported by module
|
|
string, which is still the preferred interface, without loss of
|
|
performance except during initialization). Some of these functions
|
|
(e.g. index()) could easily be implemented as string methods instead,
|
|
but others (e.g. sort()) can't, since their interface prescribes that
|
|
they modify the object, while strings are immutable (see the previous
|
|
question).
|
|
|
|
6.7. Q. Why does Python use methods for some functionality
|
|
(e.g. list.index()) but functions for other (e.g. len(list))?
|
|
|
|
A. Functions are used for those operations that are generic for a
|
|
group of types and which should work even for objects that don't have
|
|
methods at all (e.g. numbers, strings, tuples). Also, implementing
|
|
len(), max(), min() as a built-in function is actually less code than
|
|
implementing them as methods for each type. One can quibble about
|
|
individual cases but it's really too late to change such things
|
|
fundamentally now.
|
|
|
|
6.8. Q. Why can't I derive a class from built-in types (e.g. lists or
|
|
files)?
|
|
|
|
A. This is caused by the relatively late addition of (user-defined)
|
|
classes to the language -- the implementation framework doesn't easily
|
|
allow it. See the answer to question 4.2 for a work-around. This
|
|
*may* be fixed in the (distant) future.
|
|
|
|
6.9. Q. Why must 'self' be declared and used explicitly in method
|
|
definitions and calls?
|
|
|
|
A. By asking this question you reveal your C++ background. :-)
|
|
When I added classes, this was (again) the simplest way of
|
|
implementing methods without too many changes to the interpreter. I
|
|
borrowed the idea from Modula-3. It turns out to be very useful, for
|
|
a variety of reasons.
|
|
|
|
First, it makes it more obvious that you are using a method or
|
|
instance attribute instead of a local variable. Reading "self.x" or
|
|
"self.meth()" makes it absolutely clear that an instance variable or
|
|
method is used even if you don't know the class definition by heart.
|
|
In C++, you can sort of tell by the lack of a local variable
|
|
declaration (assuming globals are rare or easily recognizable) -- but
|
|
in Python, there are no local variable declarations, so you'd have to
|
|
look up the class definition to be sure.
|
|
|
|
Second, it means that no special syntax is necessary if you want to
|
|
explicitly reference or call the method from a particular class. In
|
|
C++, if you want to use a method from base class that is overridden in
|
|
a derived class, you have to use the :: operator -- in Python you can
|
|
write baseclass.methodname(self, <argument list>). This is
|
|
particularly useful for __init__() methods, and in general in cases
|
|
where a derived class method wants to extend the base class method of
|
|
the same name and thus has to call the base class method somehow.
|
|
|
|
Lastly, for instance variables, it solves a syntactic problem with
|
|
assignment: since local variables in Python are (by definition!) those
|
|
variables to which a value assigned in a function body (and that
|
|
aren't explicitly declared global), there has to be some way to tell
|
|
the interpreter that an assignment was meant to assign to an instance
|
|
variable instead of to a local variable, and it should preferably be
|
|
syntactic (for efficiency reasons). C++ does this through
|
|
declarations, but Python doesn't have declarations and it would be a
|
|
pity having to introduce them just for this purpose. Using the
|
|
explicit "self.var" solves this nicely. Similarly, for using instance
|
|
variables, having to write "self.var" means that references to
|
|
unqualified names inside a method don't have to search the instance's
|
|
directories.
|
|
|
|
6.10. Q. Can't you emulate threads in the interpreter instead of
|
|
relying on an OS-specific thread implementation?
|
|
|
|
A. Unfortunately, the interpreter pushes at least one C stack frame
|
|
for each Python stack frame. Also, extensions can call back into
|
|
Python at almost random moments. Therefore a complete threads
|
|
implementation requires thread support for C.
|
|
|
|
6.11. Q. Why can't lambda forms contain statements?
|
|
|
|
A. Python lambda forms cannot contain statements because Python's
|
|
syntactic framework can't handle statements nested inside expressions.
|
|
|
|
However, in Python, this is not a serious problem. Unlike lambda
|
|
forms in other languages, where they add functionality, Python lambdas
|
|
are only a shorthand notation if you're too lazy to define a function.
|
|
|
|
Functions are already first class objects in Python, and can be
|
|
declared in a local scope. Therefore the only advantage of using a
|
|
lambda form instead of a locally-defined function is that you'll have
|
|
to invent a name for the function -- but that's just a local variable
|
|
to which the function object (which is exactly the same type of object
|
|
that a lambda form yields) is assigned!
|
|
|
|
6.12. Q. Why is there no more efficient way of iterating over a dictionary
|
|
than first constructing the list of keys()?
|
|
|
|
A. Have you tried it? I bet it's fast enough for your purposes! In
|
|
most cases such a list takes only a few percent of the space occupied
|
|
by the dictionary -- it needs only 4 bytes (the size of a pointer) per
|
|
key -- a dictionary costs 8 bytes per key plus between 30 and 70
|
|
percent hash table overhead, plus the space for the keys and values --
|
|
by necessity all keys are unique objects and a string object (the most
|
|
common key type) costs at least 18 bytes plus the length of the
|
|
string. Add to that the values contained in the dictionary, and you
|
|
see that 4 bytes more per item really isn't that much more memory...
|
|
|
|
A call to dict.keys() makes one fast scan over the dictionary
|
|
(internally, the iteration function does exist) copying the pointers
|
|
to the key objects into a pre-allocated list object of the right size.
|
|
The iteration time isn't lost (since you'll have to iterate anyway --
|
|
unless in the majority of cases your loop terminates very prematurely
|
|
(which I doubt since you're getting the keys in random order).
|
|
|
|
I don't expose the dictionary iteration operation to Python
|
|
programmers because the dictionary shouldn't be modified during the
|
|
entire iteration -- if it is, there's a very small chance that the
|
|
dictionary is reorganized because the hash table becomes too full, and
|
|
then the iteration may miss some items and see others twice. Exactly
|
|
because this only occurs rarely, it would lead to hidden bugs in
|
|
programs: it's easy never to have it happen during test runs if you
|
|
only insert or delete a few items per iteration -- but your users will
|
|
surely hit upon it sooner or later.
|
|
|
|
6.13. Q. Can Python be compiled to machine code, C or some other language?
|
|
|
|
A. Not easily. Python's high level data types, dynamic typing of
|
|
objects and run-time invocation of the interpreter (using eval() or
|
|
exec) together mean that a "compiled" Python program would probably
|
|
consist mostly of calls into the Python run-time system, even for
|
|
seemingly simple operations like "x+1". Thus, the performance gain
|
|
would probably be minimal.
|
|
|
|
Internally, Python source code is always translated into a "virtual
|
|
machine code" or "byte code" representation before it is interpreted
|
|
(by the "Python virtual machine" or "bytecode interpreter"). In order
|
|
to avoid the overhead of parsing and translating modules that rarely
|
|
change over and over again, this byte code is written on a file whose
|
|
name ends in ".pyc" whenever a module is parsed (from a file whose
|
|
name ends in ".py"). When the corresponding .py file is changed, it
|
|
is parsed and translated again and the .pyc file is rewritten. There
|
|
is no performance difference once the .pyc file has been loaded (the
|
|
bytecode read from the .pyc file is exactly the same as the bytecode
|
|
created by direct translation). The only difference is that loading
|
|
code from a .pyc file is faster than parsing and translating a .py
|
|
file, so the presence of precompiled .pyc files will generally improve
|
|
start-up time of Python scripts. If desired, the Lib/compileall.py
|
|
module/script can be used to force creation of valid .pyc files for a
|
|
given set of modules.
|
|
|
|
If you are looking for a way to translate Python programs in order to
|
|
distribute them in binary form, without the need to distribute the
|
|
interpreter and library as well, have a look at the freeze.py script
|
|
in the Tools/freeze directory. This creates a single binary file
|
|
incorporating your program, the Python interpreter, and those parts of
|
|
the Python library that are needed by your program. Of course, the
|
|
resulting binary will only run on the same type of platform as that
|
|
used to create it.
|
|
|
|
Hints for proper usage of freeze.py:
|
|
|
|
- the script must be in a file whose name ends in .py
|
|
|
|
- you must have installed Python fully:
|
|
|
|
make install
|
|
make libinstall
|
|
make inclinstall
|
|
make libainstall
|
|
|
|
|
|
7. Using Python on non-UNIX platforms
|
|
=====================================
|
|
|
|
7.1. Q. Is there a Mac version of Python?
|
|
|
|
A. Yes, see the "mac" subdirectory of the distribution sites,
|
|
e.g. <URL:ftp://ftp.python.org/pub/python/mac/>.
|
|
|
|
7.2. Q. Is there a DOS version of Python?
|
|
|
|
A. Yes, see the "pc" subdirectory of the distribution sites,
|
|
e.g. <URL:ftp://ftp.python.org/pub/python/pc/>.
|
|
|
|
7.3. Q. Is there a Windows 3.1(1) version of Python?
|
|
|
|
A. Yes, also see the "pc" subdirectory of the distribution sites,
|
|
e.g. <URL:ftp://ftp.python.org/pub/python/pc/>. You may also be able
|
|
to run either of the Windows NT versions (see next question) if you
|
|
have Microsoft's "win32s".
|
|
|
|
7.4. Q. Is there a Windows NT version of Python?
|
|
|
|
A. There are two, both sporting DLL support for dynamic loading of
|
|
Python modules, and extensions to access the Win32 GUI API.
|
|
|
|
Mark Hammond <MHammond@cmutual.com.au> maintains an NT port which
|
|
includes an interface to the Microsoft Foundation Classes and a Python
|
|
programming environment using it that's written mostly in Python. See
|
|
<URL:ftp://ftp.python.org/pub/python/nt/>.
|
|
|
|
Jim Ahlstrom's WPY portable GUI runs on Windows NT and is modeled
|
|
after the Microsoft Foundation Classes. Source and binaries are
|
|
available in <URL:ftp://ftp.python.org/pub/python/wpy>.
|
|
|
|
Sam Rushing <rushing@squirl.oau.org> once announced he knows how to
|
|
build Python for the Windows NT on the DEC Alpha AXP.
|
|
|
|
Note that currently there is no unified compilation environment for
|
|
all NT platforms -- hopefully Microsoft will fix this with the release
|
|
of Visual C++ 2.0.
|
|
|
|
7.5. Q. Is there a Windows 95 version of Python?
|
|
|
|
A. The Windows NT versions might work, otherwise the Windows 3.1(1)
|
|
version should work (isn't Windows 95 supposed to be backwards
|
|
compatible?).
|
|
|
|
7.6. Q. Is there an OS/2 version of Python?
|
|
|
|
A. Yes, also see the "pc" subdirectory of the distribution sites,
|
|
e.g. <URL:ftp://ftp.python.org/pub/python/pc/>.
|
|
|
|
7.7. Q. Is there a VMS version of Python?
|
|
|
|
A. Donn Cave <donn@cac.washington.edu> did a partial port. The
|
|
results of his efforts are on public display in
|
|
<<URL:ftp://ftp.python.org/pub/python/contrib/vms.tar.gz/>. Someone
|
|
else is working on a more complete port, for details watch the list.
|
|
|
|
7.8. Q. What about IBM mainframes, or other non-UNIX platforms?
|
|
|
|
A. I haven't heard about these, except I remember hearing about an
|
|
OS/9 port and a port to Vxworks (both operating systems for embedded
|
|
systems). If you're interested in any of this, go directly to the
|
|
newsgroup and ask there, you may find exactly what you need. For
|
|
example, a port to MPE/iX 5.0 on HP3000 computers was just announced,
|
|
see <URL:http://www.allegro.com/software/>.
|
|
|
|
7.9. Q. Where are the source or Makefiles for the non-UNIX versions?
|
|
|
|
A. The standard sources can (almost) be used. Additional sources can
|
|
be found in the platform-specific subdirectories of the distribution.
|
|
|
|
7.10. Q. What is the status and support for the non-UNIX versions?
|
|
|
|
A. I don't have access to most of these platforms, so in general I am
|
|
dependent on material submitted by volunteers(*). However I strive to
|
|
integrate all changes needed to get it to compile on a particular
|
|
platform back into the standard sources, so porting of the next
|
|
version to the various non-UNIX platforms should be easy.
|
|
|
|
(*) For the Macintosh, that volunteer is me, with help from Jack
|
|
Jansen <jack@cwi.nl>.
|
|
|
|
7.11. Q. I have a PC version but it appears to be only a binary.
|
|
Where's the library?
|
|
|
|
A. You still need to copy the files from the distribution directory
|
|
"python/Lib" to your system. If you don't have the full distribution,
|
|
you can get the file lib<version>.tar.gz from most ftp sites carrying
|
|
Python; this is a subset of the distribution containing just those
|
|
files, e.g. <URL:ftp://ftp.python.org/pub/python/src/lib1.1.tar.gz>.
|
|
|
|
Once you have installed the library, you need to point sys.path to it.
|
|
Assuming the library is in C:\misc\python\lib, the following commands
|
|
will point your Python interpreter to it (note the doubled backslashes
|
|
-- you can also use single forward slashes instead):
|
|
|
|
>>> import sys
|
|
>>> sys.path.insert(0, 'C:\\misc\\python\\lib')
|
|
>>>
|
|
|
|
For a more permanent effect, set the environment variable PYTHONPATH,
|
|
as follows (talking to a DOS prompt):
|
|
|
|
C> SET PYTHONPATH=C:\misc\python\lib
|
|
|
|
7.12. Q. Where's the documentation for the Mac or PC version?
|
|
|
|
A. The documentation for the Unix version also applies to the Mac and
|
|
PC versions. Where applicable, differences are indicated in the text.
|
|
|
|
7.13. Q. The Mac (PC) version doesn't seem to have any facilities for
|
|
creating or editing programs apart from entering it interactively, and
|
|
there seems to be no way to save code that was entered interactively.
|
|
How do I create a Python program on the Mac (PC)?
|
|
|
|
A. Use an external editor. On the Mac, BBEdit seems to be a popular
|
|
no-frills text editor. I work like this: start the interpreter; edit
|
|
a module file using BBedit; import and test it in the interpreter;
|
|
edit again in BBedit; then use the built-in function reload() to
|
|
re-read the imported module; etc.
|
|
|
|
Regarding the same question for the PC, Kurt Wm. Hemr writes: "While
|
|
anyone with a pulse could certainly figure out how to do the same on
|
|
MS-Windows, I would recommend the NotGNU Emacs clone for MS-Windows.
|
|
Not only can you easily resave and "reload()" from Python after making
|
|
changes, but since WinNot auto-copies to the clipboard any text you
|
|
select, you can simply select the entire procedure (function) which
|
|
you changed in WinNot, switch to QWPython, and shift-ins to reenter
|
|
the changed program unit."
|