| Subject: FAQ: Python -- an object-oriented language |
| Newsgroups: comp.lang.python,comp.answers,news.answers |
| Followup-to: comp.lang.python |
| From: guido@cnri.reston.va.us (Guido van Rossum) |
| Reply-to: guido@cnri.reston.va.us (Guido van Rossum) |
| Expires: Sun, 1 Dec 1996 00:00:00 GMT |
| Supersedes: <DxJ3t1.CJv@cwi.nl> |
| Approved: news-answers-request@MIT.Edu |
| |
| Archive-name: python-faq/part1 |
| Submitted-by: Guido van Rossum <guido@cnri.reston.va.us> |
| Version: $Revision$ |
| Last-modified: $Date$ |
| |
| 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-1996 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 20191 |
| U.S.A. |
| Email: <guido@python.org>, <guido@cnri.reston.va.us> |
| |
| The latest version of this FAQ is available by anonymous ftp from |
| <URL:ftp://ftp.python.org/pub/python/doc/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 copyright restrictions on the use of Python? |
| 1.15. Q. Why was Python created in the first place? |
| |
| 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. What new developments are expected for Python in the future? |
| 2.6. Q. Is it reasonable to propose incompatible changes to Python? |
| 2.7. Q. What is the future of Python? |
| 2.8. Q. What is the PSA, anyway? |
| 2.9. Q. How do I join the PSA? |
| 2.10. Q. What are the benefits of joining the PSA? |
| |
| 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. I use VPATH but some targets are built in the source directory. |
| 3.7. Q. Trouble building or linking with the GNU readline library. |
| 3.8. Q. Trouble with socket I/O on older Linux 1.x versions. |
| 3.9. Q. Trouble with prototypes on Ultrix. |
| 3.10. Q. Other trouble building Python on platform X. |
| 3.11. Q. How to configure dynamic loading on Linux. |
| 3.12. Q: I can't get shared modules to work on Linux 2.0 (Slackware96)? |
| 3.13. Q. How to use threads on Linux. |
| 3.14. Q. Errors when linking with a shared library containing C++ code. |
| 3.15. Q. I built with tkintermodule.c enabled but get "Tkinter not found". |
| 3.16. Q. I built with Tk 4.0 but Tkinter complains about the Tk version. |
| 3.17. Q. Link errors for Tcl/Tk symbols when linking with Tcl/Tk. |
| 3.18. Q. I configured and built Python for Tcl/Tk but "import Tkinter" |
| fails. |
| 3.19. Q. Tk doesn't work right on DEC Alpha. |
| 3.20. Q. Several common system calls are missing from the posix module. |
| 3.21. Q. ImportError: No module named string, on MS Windows. |
| 3.22. Q. Core dump on SGI when using the gl module. |
| |
| 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())? |
| 4.34. Q. Can I have Tk events handled while waiting for I/O? |
| 4.35. Q. How do I write a function with output parameters (call by reference)? |
| 4.36. Q. Please explain the rules for local and global variables in Python. |
| 4.37. Q. How can I have modules that mutually import each other? |
| 4.38. Q. How do I copy an object in Python? |
| 4.39. Q. How to implement persistent objects in Python? (Persistent == |
| automatically saved to and restored from disk.) |
| 4.40. Q. I try to use __spam and I get an error about _SomeClassName__spam. |
| |
| 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. How do I call an object's method from C? |
| 5.8. Q. How do I catch the output from print_error()? |
| 5.9. Q. How do I access a module written in Python from C? |
| 5.10. Q. How do I interface to C++ objects from Python? |
| |
| 6. Python's design |
| 6.1. Q. Why isn't there a switch or case statement in Python? |
| 6.2. Q. Why does Python use indentation for grouping of statements? |
| 6.3. Q. Why are Python strings immutable? |
| 6.4. Q. Why don't strings have methods like index() or sort(), like |
| lists? |
| 6.5. Q. Why does Python use methods for some functionality |
| (e.g. list.index()) but functions for other (e.g. len(list))? |
| 6.6. Q. Why can't I derive a class from built-in types (e.g. lists or |
| files)? |
| 6.7. Q. Why must 'self' be declared and used explicitly in method |
| definitions and calls? |
| 6.8. Q. Can't you emulate threads in the interpreter instead of |
| relying on an OS-specific thread implementation? |
| 6.9. Q. Why can't lambda forms contain statements? |
| 6.10. Q. Why don't lambdas have access to variables defined in the |
| containing scope? |
| 6.11. Q. Why can't recursive functions be defined inside other functions? |
| 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? |
| 6.14. Q. Why doesn't Python use proper garbage collection? |
| |
| 7. Using Python on non-UNIX platforms |
| 7.1. Q. Is there a Mac version of Python? |
| 7.2. Q. Are there DOS and Windows versions of Python? |
| 7.3. Q. Is there an OS/2 version of Python? |
| 7.4. Q. Is there a VMS version of Python? |
| 7.5. Q. What about IBM mainframes, or other non-UNIX platforms? |
| 7.6. Q. Where are the source or Makefiles for the non-UNIX versions? |
| 7.7. Q. What is the status and support for the non-UNIX versions? |
| 7.8. Q. I have a PC version but it appears to be only a binary. |
| Where's the library? |
| 7.9. Q. Where's the documentation for the Mac or PC version? |
| 7.10. 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.3.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.) |
| |
| Sometimes beta versions of a newer release are available; check the |
| subdirectory "beta" of the above-mentioned URL (i.e. |
| <URL:ftp://ftp.python.org/pub/python/src/beta/>). (At the time of |
| writing, beta3 for Python 1.4 is available there, and should be |
| checked before reporting problems with version 1.3.) |
| |
| 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.) |
| |
| 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: |
| |
| USA: |
| |
| <URL:ftp://ftp.python.org/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.sterling.com/programming/languages/python/> |
| <URL:ftp://uiarchive.cso.uiuc.edu/pub/lang/python/> |
| <URL:ftp://ftp.pht.com/mirrors/python/python/> |
| |
| Europe: |
| |
| <URL:ftp://ftp.cwi.nl/pub/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.ibp.fr/pub/python/> |
| <URL:ftp://ftp.switch.ch/software/sources/python/> |
| <URL:ftp://ftp.informatik.tu-muenchen.de/pub/comp/programming/languages/python/> |
| |
| Australia: |
| |
| <URL:ftp://ftp.dstc.edu.au/pub/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. |
| |
| See also the next section (supposedly Aaron Watters' paper has been |
| refereed). |
| |
| 1.11. Q. Are there short introductory papers or talks on Python? |
| |
| A. 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", |
| <URL: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 |
| <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 1994 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 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 "betaN" for some small |
| number N. Note that (for instance) all versions labeled 1.4betaN |
| *precede* the actual release of 1.4. 1.4b3 is short for 1.4beta3. |
| |
| 1.13. Q. How do I get a beta test version of Python? |
| |
| A. If there are any beta releases, they are published in the normal |
| source directory (e.g. <URL:ftp://ftp.python.org/pub/python/src/>). |
| |
| 1.14. 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.15. 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. |
| |
| |
| 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>. |
| |
| 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.3) have been coming out roughly every 3 to |
| 6 months for the past four years. |
| |
| 2.5. 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.6. 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.7. 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! |
| |
| 2.8. Q. What is the PSA, anyway? |
| |
| A. The Python Software Activity <URL: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 <URL:http://www.cnri.reston.va.us>. Anybody who |
| wishes Python well should join the PSA. |
| |
| 2.9. Q. How do I join the PSA? |
| |
| A. The full scoop is available on the web, see |
| <URL: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 20191. Full-time students pay $25. Companies can join for |
| a mere $500. |
| |
| 2.10. Q. What are the benefits of joining the PSA? |
| |
| A. 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 <URL: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. |
| |
| |
| 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. 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.7. 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.8. Q. Trouble with socket I/O on older Linux 1.x versions. |
| |
| A. 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. |
| |
| 3.9. Q. Trouble with prototypes on Ultrix. |
| |
| A. Ultrix cc seems broken -- use gcc, or edit config.h to #undef |
| HAVE_PROTOTYPES. |
| |
| 3.10. Q. Other trouble building Python on platform X. |
| |
| A. Please email the details to <guido@cnri.reston.va.us> 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.11. Q. How to configure dynamic loading on Linux. |
| |
| A. This is now automatic as long as your Linux version uses the ELF |
| object format (all recent Linuxes do). |
| |
| 3.12. Q: I can't get shared modules to work on Linux 2.0 (Slackware96)? |
| |
| A: This is a bug in the Slackware96 release. The fix is simple: |
| |
| Make sure that there is a link from /lib/libdl.so to /lib/libdl.so.1 |
| so that the following links are setup: |
| |
| /lib/libdl.so -> /lib/libdl.so.1 |
| /lib/libdl.so.1 -> /lib/libdl.so.1.7.14 |
| |
| 3.13. Q. How to use threads on Linux. |
| |
| A. [Greg Stein] I built myself a libpthreads.so from the libc.5.3.12 |
| distribution (the binary distribution doesn't have pthreads in |
| it). Then, I configured Python with --with-threads and then tweaked |
| config.h to include a #define _MIT_POSIX_THREADS (or something like |
| that, see /usr/include/pthreads.h). It worked fine at that point. |
| |
| Note that I couldn't get threading to "operate well" with any of the |
| other thread packages. Prior libc versions didn't integrate well with |
| threads, either, so I couldn't use them (e.g. sleep() blocked all |
| threads :-( ). |
| |
| 3.14. 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.15. 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.16. 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.17. Q. Link errors for Tcl/Tk symbols when linking with Tcl/Tk. |
| |
| Quite possibly, there's a version mismatch between the Tcl/Tk header |
| files (tcl.h and tk.h) and the tck/tk libraries you are using (the |
| "-ltk4.0" and "-ltcl7.4" arguments for _tkinter in the Setup file). |
| If you have installed both versions 7.4/4.0 and 7.5/4.1 of Tcl/Tk, |
| most likely your header files are for The newer versions, but the |
| Setup line for _tkinter in some Python distributions references |
| 7.4/4.0 by default. Changing this to 7.5/4.1 should take care of |
| this. |
| |
| 3.18. Q. I configured and built Python for Tcl/Tk but "import Tkinter" |
| fails. |
| |
| A. Most likely, you forgot to enable the line in Setup that says |
| "TKPATH=:$(DESTLIB)/tkinter". |
| |
| 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. |
| |
| 3.20. Q. Several common system calls are missing from the posix module. |
| |
| A. 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. |
| |
| 3.21. Q. ImportError: No module named string, on MS Windows. |
| |
| A. 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) |
| |
| 3.22. Q. 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. |
| |
| |
| |
| 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. |
| |
| Currently supported solutions: |
| |
| - There's a neat object-oriented interface to the Tcl/Tk widget set, |
| called Tkinter. It is part of the standard Python distribution and |
| well-supported -- all you need to do is build and install Tcl/Tk and |
| enable the _tkinter module and the TKPATH definition in Modules/Setup |
| when building Python. 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/>. Tcl/Tk is now fully |
| portable to the Mac and Windows platforms (NT and 95 only); you need |
| Python 1.4beta3 or later and Tk 4.1patch1 or later. |
| |
| - 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) available from |
| <URL:ftp://ftp.python.org/pub/python/src/X-extension.tar.gz>. |
| Support by Sjoerd Mullender <sjoerd@cwi.nl>. |
| |
| - On top of the X11 interface there's the (recently revived) vpApp |
| toolkit by Per Spilling, now also maintained by Sjoerd Mullender |
| <sjoerd@cwi.nl>. See <URL:ftp://ftp.cwi.nl/pub/sjoerd/vpApp.tar.gz>. |
| |
| - The Mac port has a rich and ever-growing set of modules that support |
| the native Mac toolbox calls. See the documentation that comes with |
| the Mac port. See <URL:ftp://ftp.python.org/pub/python/mac>. Support |
| by Jack Jansen <jack@cwi.nl>. |
| |
| - The NT port supported by Mark Hammond <MHammond@skippinet.com.au> |
| (see question 7.2) 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/pythonwin/>. |
| |
| - There's an object-oriented GUI based on the Microsoft Foundation |
| Classes model called WPY, supported by Jim Ahlstrom <jim@interet.com>. |
| Programs written in WPY run unchanged and with native look and feel on |
| Windows NT/95, Windows 3.1 (using win32s), and on Unix (using Tk). |
| Source and binaries for Windows and Linux are available in |
| <URL:ftp://ftp.python.org/pub/python/wpy/>. |
| |
| Obsolete or minority solutions: |
| |
| - 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>. |
| Support for wxPython (by Harri Pasanen <pa@tekla.fi>) appears |
| to have a low priority. |
| |
| - For SGI IRIX only, there are unsupported interfaces 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/>). This is probably also |
| becoming obsolete, as OpenGL takes over. |
| |
| - There's an interface to STDWIN, a platform-independent low-level |
| windowing interface for Mac and X11. This is totally unsupported and |
| rapidly becoming obsolete. The STDWIN sources are at |
| <URL:ftp://ftp.cwi.nl/pub/stdwin/>. (For info about STDWIN 2.0, |
| please refer to Steven Pemberton <steven@cwi.nl> -- I believe it is |
| also dead.) |
| |
| - There once was an interface to WAFE, a Tcl interface to the X11 |
| Motif and Athena widget sets. WAFE is at |
| <URL:ftp://ftp.wu-wien.ac.at/pub/src/X11/wafe/>. It's not clear what |
| the status of the Python support is. |
| |
| - (The Fresco port that was mentioned in earlier versions of this FAQ |
| no longer seems to exist. Inquire with Mark Linton.) |
| |
| 4.14. Q. Are there any interfaces to database packages in Python? |
| |
| A. There's a whole collection of them in the contrib area of the ftp |
| server, see <URL:http://www.python.org/ftp/python/contrib/Database/>. |
| |
| 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. |
| |
| Tim Peters (who wishes it was Steve Majewski) 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, if your __del__ method raises an exception, this will be |
| ignored. Starting with Python 1.4beta3, a warning message is printed |
| to sys.stderr when this happens. |
| |
| 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. See the chapter titled "Internet and WWW" in the Library Reference |
| Manual. There's also a web browser written in Python, called Grail -- |
| see <URL:http://monty.cnri.reston.va.us/grail/>. |
| |
| 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(). |
| |
| 4.34. Q. Can I have Tk events handled while waiting for I/O? |
| |
| A. 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: |
| |
| from Tkinter import tkinter |
| tkinter.createfilehandler(file, mask, callback) |
| |
| 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: |
| |
| callback(file, mask) |
| |
| You must unregister the callback when you're done, using |
| |
| tkinter.deletefilehandler(file) |
| |
| 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). |
| |
| 4.35. Q. How do I write a function with output parameters (call by reference)? |
| |
| A. [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): |
| a[0] = 'new-value' # 'a' references a mutable list |
| a[1] = a[1] + 1 # changes a shared object |
| |
| 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): |
| a = 'new-value' # a and b are local names |
| b = b + 1 # assigned to new objects |
| return a, b # return new values |
| |
| 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'] = 'new-value' # args is a mutable dictionary |
| args['b'] = args['b'] + 1 # change it in-place |
| |
| 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 __init__(self, **args): |
| for (key, value) in args.items(): |
| setattr(self, key, value) |
| |
| def func4(args): |
| args.a = 'new-value' # args is a mutable callByRef |
| args.b = args.b + 1 # change object in-place |
| |
| 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.] |
| |
| 4.36. Q. Please explain the rules for local and global variables in Python. |
| |
| A. [Ken Manheimer] In Python, procedure variables are implicitly |
| global, unless they assigned anywhere within the block. In that case |
| they are implicitly local, and you need to explicitly declare them as |
| 'global'. |
| |
| Though a bit surprising at first, a moments consideration explains |
| this. On one hand, requirement of 'global' for assigned vars provides |
| a bar against unintended side-effects. On the other hand, if global |
| were required for all global references, you'd be using global all the |
| time. Eg, you'd have to declare as global every reference to a |
| builtin function, or to a component of an imported module. This |
| clutter would defeat the usefulness of the 'global' declaration for |
| identifying side-effects. |
| |
| 4.37. Q. How can I have modules that mutually import each other? |
| |
| A. Jim Roskind recommends the following order in each module: |
| |
| First: all exports (like globals, functions, and classes that don't |
| need imported bases classes). |
| |
| Then: all import statements. |
| |
| Finally: all active code (including globals that are initialized from |
| imported values). |
| |
| Python's author doesn't like this approach much because the imports |
| appear in a strange place, but has to admit that it works. His |
| recommended strategy is to avoid all uses of "from <module> import *" |
| (so everything from an imported module is referenced as |
| <module>.<name>) and to place all code inside functions. |
| Initializations of global variables and class variables should use |
| constants or built-in functions only. |
| |
| 4.38. Q. How do I copy an object in Python? |
| |
| A. There is no generic copying operation built into Python, however |
| most object types have some way to create a clone. Here's how for the |
| most common objects: |
| |
| - For immutable objects (numbers, strings, tuples), cloning is |
| unnecessary since their value can't change. |
| |
| - For lists (and generally for mutable sequence types), a clone is |
| created by the expression l[:]. |
| |
| - For dictionaries, the following function returns a clone: |
| |
| def dictclone(o): |
| n = {} |
| for k in o.keys(): n[k] = o[k] |
| return n |
| |
| - Finally, for generic objects, the "copy" module defines two |
| functions for copying objects. copy.copy(x) returns a copy as shown |
| by the above rules. copy.deepcopy(x) also copies the elements of |
| composite objects. See the section on this module in the Library |
| Reference Manual. |
| |
| 4.39. Q. How to implement persistent objects in Python? (Persistent == |
| automatically saved to and restored from disk.) |
| |
| A. 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. |
| |
| 4.40. Q. I try to use __spam and I get an error about _SomeClassName__spam. |
| |
| A. Variables with double leading underscore are "mangled" to provide a |
| simple but effective way to define class private variables. See the |
| chapter "New in Release 1.4" in the Python Tutorial. |
| |
| |
| 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. 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.8. 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. |
| |
| * 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.9. 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.10. 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 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.2. 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.3. 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.4. 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.5. 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.6. 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.7. 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.8. 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.9. 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.10. Q. Why don't lambdas have access to variables defined in the |
| containing scope? |
| |
| A. Because they are implemented as ordinary functions. |
| See question 4.5 above. |
| |
| 6.11. Q. Why can't recursive functions be defined inside other functions? |
| |
| A. See question 4.5 above. |
| |
| 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 |
| |
| 6.14. Q. Why doesn't Python use proper garbage collection? |
| |
| A. 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: |
| |
| for file in <very long list of files>: |
| f = open(file) |
| c = file.read(1) |
| |
| 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. |
| |
| |
| 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. Are there DOS and Windows versions of Python? |
| |
| A. Yes. There is a plethora of not-always-compatible versions. See |
| the "pythonwin", "wpy", "nt" and "pc" subdirectories of the |
| distribution sites. A quick comparison: |
| |
| PythonWin: Extensive support for the 32-bit native Windows API and GUI |
| building using MFC. Windows NT and Windows 95 only (and Windows |
| 3.1(1) using win32s, until Microsoft stops supporting it :-( ). |
| <URL:ftp://ftp.python.org/pub/python/pythonwin/>. |
| |
| WPY: Ports to DOS, Windows 3.1(1), Windows 95, Windows NT and OS/2. |
| Also contains a GUI package that offers portability between Windows |
| (not DOS) and Unix, and native look and feel on both. |
| <URL:ftp://ftp.python.org/pub/python/wpy/>. |
| |
| NT: Basic ports built straight from the 1.4 distribution for Windows |
| 95 and Windows NT. This will eventually provide core support for |
| both PythonWin and WPY on all 32-bit Microsoft platforms. |
| <URL:ftp://ftp.python.org/pub/python/nt/>. |
| |
| PC: Old, unsupported ports to DOS, Windows 3.1(1) and OS/2. |
| <URL:ftp://ftp.python.org/pub/python/pc/>. |
| |
| 7.3. Q. Is there an OS/2 version of Python? |
| |
| A. Yes, see the "pc" and "wpy" subdirectory of the distribution sites |
| (see above). |
| |
| 7.4. 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.5. 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.6. 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.7. 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.8. 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.9. 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.10. 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." |