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: Wed, 1 Nov 1995 00:00:00 GMT Supersedes: DFMAv8.3Hp@cwi.nl Approved: news-answers-request@MIT.Edu
Archive-name: python-faq/part1 Submitted-by: Guido van Rossum guido@cwi.nl Version: 1.31 Last-modified: 26 June 1996
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 ftp://ftp.python.org/pub/python/doc/FAQ. It will also be posted regularly to the newsgroups comp.answers news:comp.answers and comp.lang.python news:comp.lang.python.
Many FAQs, including this one, are available by anonymous ftp 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 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:
Here's an overview of the questions per chapter:
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).
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 :-)
How do I obtain a copy of the Python source?
The latest complete Python source distribution is always available by anonymous ftp, e.g. 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. 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, ftp://ftp.python.org/pub/python/index.html.
How do I get documentation on Python?
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. 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).
Are there other ftp sites that mirror the Python distribution?
The following anonymous ftp sites keep mirrors of the Python distribution:
USA:
Europe:
Australia:
Or try archie on the string "python".
Is there a newsgroup or mailing list devoted to Python?
There is a newsgroup, comp.lang.python 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, http://www.cwi.nl/~guido/hypermail/index.html. The raw archives are also available by ftp, e.g. 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.)
Is there a WWW page devoted to Python?
Yes, 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: http://www.cwi.nl/~guido/Python.html or at the U.S. copy: http://www.python.org/~guido/Python.html.
Is the Python documentation available on the WWW?
Yes, see 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. 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. ftp://ftp.python.org/pub/python/doc/lib-info.tar.gz.
Is there a book on Python, or will there be one out soon?
Mark Lutz is writing a Python book for O'Reilly and Associates, to be published early 1996. See the outline (in PostScript): http://www.python.org/workshops/1995-05/outlinep.eps.
Are there any published articles about Python that I can quote?
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.
See also the next section (supposedly Aaron Watters' paper has been refereed).
Are there short introductory papers or talks on Python?
A recent, very entertaining introduction to Python is the tutorial by Aaron Watters in UnixWorld Online:
Aaron R. Watters: "The What, Why, Who, and Where of Python", http://www.wcmh.com/uworld/archives/95/tutorial/005.html
An olded paper 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 ftp://ftp.python.org/pub/python/doc/nluug-paper.ps and 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 1994 are available as ftp://ftp.python.org/pub/python/doc/vhll-slides.ps.
How does the Python version numbering scheme work?
Python versions are numbered A.B.C or A.B. 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 patch release. Not all releases have patch releases. 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.3b1 is short for 1.3-beta-1.
How do I get a beta test version of Python?
If there are any beta releases, they are published in the normal source directory (e.g. ftp://ftp.python.org/pub/python/src/).
Are there copyright restrictions on the use of Python?
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!
Why was Python created in the first place?
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.
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.
How many people are using Python?
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 http://www.python.org/stats/.
Have any significant projects been done in Python?
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 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!
Are there any commercial projects going on using Python?
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 http://www.infoseek.com/. Contact: info@infoseek.com.
Paul Everitt of Connecting Minds is planning a Lotus Notes gateway. Contact: Paul.Everitt@cminds.com. Or see their WWW server 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 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!
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.3) have been coming out roughly every 3 to 6 months for the past four years.
When will the next version be released?
Version 1.3 is being released on 13 October 1995. It is too early to predict when the next release will be necessary, but you can expect something awesome within half a year!
What new developments are expected for Python in the future?
See my Work-In-Progress web page, currently at http://www.python.org:~guido/WIP.html, and the pages for the Second Python Workshop (best reached via the Python home page, http://www.python.org/). Also follow the newsgroup discussions!
Is it reasonable to propose incompatible changes to Python?
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.
If I knew, I'd be rich :-)
Seriously, the formation of the PSA (Pyton Software Activity, see 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 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!
The Python Software Activity http://www.python.org/psa/ was created by a number of Python aficionados who want Python to be more than the product and responsibility of a single individual. It has found a home at CNRI http://www.cnri.reston.va.us. Anybody who wishes Python well should join the PSA.
The full scoop is available on the web, see http://www.python.org/psa/Joining.html. Summary: send a check of at least $50 to CNRI/PSA, 1895 Preston White Drive, Suite 100, in Reston, VA 22091. Full-time students pay $25. Companies can join for a mere $500.
What are the benefits of joining the PSA?
Like National Public Radio, if not enough people join, Python will wither. Your name will be mentioned on the PSA's web server. Workshops organized by the PSA http://www.python.org/workshops/ are only accessible to PSA members (you can join at the door). The PSA is working on additional benefits, such as reduced prices for books and software, and early access to beta versions of Python.
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.
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.
Link errors after rerunning the configure script.
It is generally necessary to run "make clean" after a configuration change.
The python interpreter complains about options passed to a
script (after the script name).
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.
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).
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).
I use VPATH but some targets are built in the source directory.
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.
Trouble building or linking with the GNU readline library.
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 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 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).
Trouble building Python on Linux.
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).
Trouble with socket I/O on Linux.
Once you've built Python, use it to run the regen.py script in the Lib/linux1 directory. Apparently the files as distributed don't match the system headers on some Linux versions.
Trouble with prototypes on Ultrix.
Ultrix cc seems broken -- use gcc, or edit config.h to #undef HAVE_PROTOTYPES.
Trouble with posix.listdir on NeXTSTEP 3.2.
(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.
Other trouble building Python on platform X.
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.
How to configure dynamic loading on Linux.
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: ftp://sunsite.unc.edu/pub/Linux/libs/dld-3.2.5.src.tar.gz and ftp://tsx-11.mit.edu/pub/linux/sources/libs/dld-3.2.5.src.tar.gz. There's also a binary distribution of it: 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 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.
Under Solaris 2.x, using GCC, how do I use shared libraries?
Use the linker in /usr/ucb/ld, not the GNU linker. The latter cannot create shared libraries.
Errors when linking with a shared library containing C++ code.
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++.
Tk menus or radiobuttons don't work properly in Python 1.2.
There's a bug in Tkinter.py; remove ClassType and InstanceType from the definition of CallableTypes near the top of Lib/tkinter/Tkinter.py.
I built with tkintermodule.c enabled but get "Tkinter not found".
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.
I built with Tk 4.0 but Tkinter complains about the Tk version.
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.
Tk doesn't work right on DEC Alpha.
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.
Several common system calls are missing from the posix module.
Most likely, *all* test compilations run by the configure script are failing for some reason or another. Have a look in config.log to see what could be the reason. A common reason is specifying a directory to the --with-readline option that doesn't contain the libreadline.a file.
ImportError: No module named string, on MS Windows.
Most likely, your PYTHONPATH environment variable should be set to something like:
set PYTHONPATH=c:\python;c:\python\lib;c:\python\scripts
(assuming Python was installed in c:\python)
Core dump on SGI when using the gl module.
There are conflicts between entry points in the termcap and curses libraries and an entry point in the GL library. There's a hack of a fix for the termcap library if it's needed for the GNU readline library, but it doesn't work when you're using curses. Concluding, you can't build a Python binary containing both the curses and gl modules.
Is there a source code level debugger with breakpoints, step,
etc.?
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.
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)
Is there a curses/termcap package for Python?
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 ftp://ftp.cwi.nl/pub/stdwin/.) This will also prepare your program for porting to windowing environments such as X11 or the Macintosh.
Is there an equivalent to C's onexit() in Python?
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.
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
How do I iterate over a sequence in reverse order?
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:
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]
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):
Unfortunately, this solution is slowest of all, due to the method call overhead...
My program is too slow. How do I speed it up?
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).
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.
How do I find the current module name?
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.
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()
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. ftp://ftp.python.org/pub/python/src/extensions.tar.gz and follow the instructions there.
See also the next question.
I have successfully built Python with STDWIN but it can't
find some modules (e.g. stdwinevents).
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.
What GUI toolkits exist for Python?
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 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. ftp://ftp.cwi.nl/pub/stdwin/ or gatekeeper.dec.com in pub/misc/stdwin 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 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 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 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 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 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 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 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 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 ftp://ftp.python.org/pub/python/wpy.
- Python has been mentioned on the "Futurism" subpage of the Fresco home page 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: http://www.faslab.com/fresco/pesto/Index.html.
Are there any interfaces to database packages in Python?
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 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). ftp://ftp.python.org/pub/python/contrib/PymSQL.tar.gz.
Tom Culliton culliton@clark.net has written an Oracle module. See ftp://ftp.clark.net/pub/culliton/oramod.tgz.
Is it possible to write obfuscated one-liners in Python?
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!
Is there an equivalent of C's "?:" ternary operator?
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'.
My class defines __del__ but it is not called when I delete the
object.
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.
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)
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.
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.
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).
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.
How do I call a method defined in a base class from a derived
class that overrides it?
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).
How do I call a method from a base class without using the
name of the base class?
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.
How can I organize my code to make it easier to change the base
class?
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 =
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.
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).
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".
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
ftp://ftp.cs.indiana.edu/pub/smiale/dancer.tar.gz. (There are a
few articles about Dancer in the (hyper)mail archive
http://www.cwi.nl/~guido/hypermail/python-1994q3/index.html.)
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:
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.
ftp://ftp.python.org/pub/python/contrib/expy-0.3.tar.gz.
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.
Assuming you're already using python-mode and font-lock-mode
separately, all you need to do is put this in your .emacs file:
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().
Yes, and you don't even need threads! But you'll have to
restructure your I/O code a bit. Tk has the equivalent of Xt's
XtAddInput() call, which allows you to register a callback function
which will be called from the Tk mainloop when I/O is possible on a
file descriptor. Here's what you need:
The file may be a Python file or socket object (actually, anything
with a fileno() method), or an integer file descriptor. The mask is
one of the constants tkinter.READABLE or tkinter.WRITABLE. The
callback is called as follows:
You must unregister the callback when you're done, using
Note: since you don't know *how many bytes* are available for reading,
you can't use the Python file object's read or readline methods, since
these will insist on reading a predefined number of bytes. For
sockets, the recv() or recvfrom() methods will work fine; for other
files, use os.read(file.fileno(), maxbytecount).
[Mark Lutz] The thing to remember is that arguments are passed by
assignment in Python. Since assignment just creates references to
objects, there's no alias between an argument name in the caller and
callee, and so no call-by-reference per se. But you can simulate it
in a number of ways:
1) By using global variables; but you probably shouldn't :-)
2) By passing a mutable (changeable in-place) object:
def func1(a):
args = ['old-value', 99]
func1(args)
print args[0], args[1] # output: new-value 100
3) By return a tuple, holding the final values of arguments:
def func2(a, b):
x, y = 'old-value', 99
x, y = func2(x, y)
print x, y # output: new-value 100
4) And other ideas that fall-out from Python's object model. For
instance, it might be clearer to pass in a mutable dictionary:
def func3(args):
args = {'a':' old-value', 'b': 99}
func3(args)
print args['a'], args['b']
5) Or bundle-up values in a class instance:
class callByRef:
def func4(args):
args = callByRef(a='old-value', b=99)
func4(args)
print args.a, args.b
But there's probably no good reason to get this complicated :-).
[Python' author favors solution 3 in most cases.]
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.
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.
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.
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.
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.
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.
It's a typo, I meant newtupleobject() (see previous question).
Here's a function (untested) that might become part of the next
release in some form. It uses
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"):
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)".
(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.
You can get a pointer to the module object as follows:
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["
You can then access the module's attributes (i.e. any name defined in
the module) as follows:
Calling setattr(), to assign to variables in the module, also works.
Depending on your requirements, there are many approaches. Begin
by reading the "Extending and Embedding" document (Doc/ext.tex, see
also 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.
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.
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.
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.
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:
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!
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)
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).
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.
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.
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,
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.
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.
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!
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.
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:
It's looking less and less likely that Python will ever get
"automatic" garbage collection (GC). For one thing, unless this were
added to C as a standard feature, it's a portability pain in the ass.
And yes, I know about the Xerox library. It has bits of assembler
code for *most* *common* platforms. Not for all. And although it is
mostly transparent, it isn't completely transparent (when I once
linked Python with it, it dumped core).
"Proper" GC also becomes a problem when Python gets embedded into
other applications. While in a stand-alone Python it may be fine to
replace the standard malloc() and free() with versions provided by the
GC library, an application embedding Python may want to have its *own*
substitute for malloc() and free(), and may not want Python's. Right
now, Python works with anything that implements malloc() and free()
properly.
Besides, the predictability of destructor calls in Python is kind of
attractive. With GC, the following code (which is fine in current
Python) will run out of file descriptors long before it runs out of
memory:
Using the current reference counting and destructor scheme, each new
assignment to f closes the previous file. Using GC, this is not
guaranteed. Sure, you can think of ways to fix this. But it's not
off-the-shelf technology.
Yes, see the "mac" subdirectory of the distribution sites,
e.g. ftp://ftp.python.org/pub/python/mac/.
Yes, see the "pc" subdirectory of the distribution sites,
e.g. ftp://ftp.python.org/pub/python/pc/.
Yes, also see the "pc" subdirectory of the distribution sites,
e.g. 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".
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
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 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.
The Windows NT versions might work, otherwise the Windows 3.1(1)
version should work (isn't Windows 95 supposed to be backwards
compatible?).
Yes, also see the "pc" subdirectory of the distribution sites,
e.g. ftp://ftp.python.org/pub/python/pc/.
Donn Cave donn@cac.washington.edu did a partial port. The
results of his efforts are on public display in
<ftp://ftp.python.org/pub/python/contrib/vms.tar.gz/. Someone
else is working on a more complete port, for details watch the list.
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 http://www.allegro.com/software/.
The standard sources can (almost) be used. Additional sources can
be found in the platform-specific subdirectories of the distribution.
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.
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
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):
For a more permanent effect, set the environment variable PYTHONPATH,
as follows (talking to a DOS prompt):
The documentation for the Unix version also applies to the Mac and
PC versions. Where applicable, differences are indicated in the text.
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."
def meth(self):
BaseAlias.meth(self)
...
How can I find the methods or attributes of an object?
I can't seem to use os.read() on a pipe created with os.popen().
How can I create a stand-alone binary from a Python script?
What WWW tools are there for Python?
How do I run a subprocess with pipes connected to both input
and output?
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
How do I call a function if I have the arguments in a tuple?
How do I enable font-lock-mode for Python in Emacs?
(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)
Is there an inverse to the format operator (a la C's scanf())?
Can I have Tk events handled while waiting for I/O?
from Tkinter import tkinter
tkinter.createfilehandler(file, mask, callback)
callback(file, mask)
tkinter.deletefilehandler(file)
How do I write a function with output parameters (call by reference)?
a[0] = 'new-value' # 'a' references a mutable list
a[1] = a[1] + 1 # changes a shared object
a = 'new-value' # a and b are local names
b = b + 1 # assigned to new objects
return a, b # return new values
args['a'] = 'new-value' # args is a mutable dictionary
args['b'] = args['b'] + 1 # change it in-place
def __init__(self, **args):
for (key, value) in args.items():
setattr(self, key, value)
args.a = 'new-value' # args is a mutable callByRef
args.b = args.b + 1 # change object in-place
Extending Python
Can I create my own functions in C?
Can I create my own functions in C++?
How can I execute arbitrary Python statements from C?
How can I evaluate an arbitrary Python expression from C?
How do I extract C values from a Python object?
How do I use mkvalue() to create a tuple of arbitrary length?
What happened to mktuple(), featured in an example in the
Extensions manual?
How do I call an object's method from C?
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;
}
res = call_method(f, "seek", "(OO)", 10, 0);
if (res == NULL) {
... an exception occurred ...
}
else {
DECREF(res);
}
How do I catch the output from print_error()?
How do I access a module written in Python from C?
module = import_module("
attr = getattr(module, "How do I interface to C++ objects from Python?
Python's design
Why isn't there a generic copying operation for objects in Python?
Why isn't there a switch or case statement in Python?
Why does Python use indentation for grouping of statements?
if (x <= y)
x++;
y--;
z++;
Why are Python strings immutable?
Why don't strings have methods like index() or sort(), like
lists?
Why can't I derive a class from built-in types (e.g. lists or
files)?
Why must 'self' be declared and used explicitly in method
definitions and calls?
Why can't lambda forms contain statements?
Can Python be compiled to machine code, C or some other language?
make install
make libinstall
make inclinstall
make libainstall
Why doesn't Python use proper garbage collection?
for file in Using Python on non-UNIX platforms
Is there a Mac version of Python?
Is there a DOS version of Python?
Is there a Windows 3.1(1) version of Python?
Is there a Windows NT version of Python?
Is there a Windows 95 version of Python?
Is there an OS/2 version of Python?
Is there a VMS version of Python?
What about IBM mainframes, or other non-UNIX platforms?
Where are the source or Makefiles for the non-UNIX versions?
What is the status and support for the non-UNIX versions?
I have a PC version but it appears to be only a binary.
Where's the library?
>>> import sys
>>> sys.path.insert(0, 'C:\\misc\\python\\lib')
>>>
C> SET PYTHONPATH=C:\misc\python\lib
Where's the documentation for the Mac or PC version?