Menu
▾
▴
py-howto-checkins — Checkins to the Python HOWTOs
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(11) |
Sep
(10) |
Oct
(11) |
Nov
(8) |
Dec
(1) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
(12) |
Feb
(7) |
Mar
(21) |
Apr
(5) |
May
(4) |
Jun
(1) |
Jul
(33) |
Aug
(5) |
Sep
(13) |
Oct
(16) |
Nov
(2) |
Dec
(6) |
| 2002 |
Jan
|
Feb
|
Mar
(6) |
Apr
(4) |
May
(1) |
Jun
|
Jul
(4) |
Aug
|
Sep
(1) |
Oct
|
Nov
(6) |
Dec
(1) |
| 2003 |
Jan
(1) |
Feb
(2) |
Mar
|
Apr
(6) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
|
From: A.M. K. <aku...@us...> - 2000-10-04 12:40:47
|
Update of /cvsroot/py-howto/pyhowto In directory slayer.i.sourceforge.net:/tmp/cvs-serv4049 Modified Files: python-2.0.tex Log Message: Rewrites to section on new development process, after Usenet discussion of the text Index: python-2.0.tex =================================================================== RCS file: /cvsroot/py-howto/pyhowto/python-2.0.tex,v retrieving revision 1.34 retrieving revision 1.35 diff -C2 -r1.34 -r1.35 *** python-2.0.tex 2000/09/27 02:49:24 1.34 --- python-2.0.tex 2000/10/04 12:40:44 1.35 *************** *** 59,94 **** The most important change in Python 2.0 may not be to the code at all, ! but to how Python is developed. - In May of 2000, the Python CVS tree was moved to SourceForge. - Previously, there were roughly 7 or so people who had write access to - the CVS tree, and all patches had to be inspected and checked in by - one of the people on this short list. Obviously, this wasn't very - scalable. By moving the CVS tree to SourceForge, it became possible - to grant write access to more people; as of September 2000 there were - 27 people able to check in changes, a fourfold increase. This makes - possible large-scale changes that wouldn't be attempted if they'd have - to be filtered through the small group of core developers. For - example, one day Peter Schneider-Kamp took it into his head to drop - K\&R C compatibility and convert the C source for Python to ANSI - C. After getting approval on the python-dev mailing list, he launched - into a flurry of checkins that lasted about a week, other developers - joined in to help, and the job was done. If there were only 5 people - with write access, probably that task would have been viewed as - ``nice, but not worth the time and effort needed'' and it would - never have gotten done. - - SourceForge also provides tools for tracking bug and patch - submissions, and in combination with the public CVS tree, they've - resulted in a remarkable increase in the speed of development. - Patches now get submitted, commented on, revised by people other than - the original submitter, and bounced back and forth between people - until the patch is deemed worth checking in. This didn't come without - a cost: developers now have more e-mail to deal with, more mailing - lists to follow, and special tools had to be written for the new - environment. For example, SourceForge sends default patch and bug - notification e-mail messages that are completely unhelpful, so Ka-Ping - Yee wrote an HTML screen-scraper that sends more useful messages. - The ease of adding code caused a few initial growing pains, such as code was checked in before it was ready or without getting clear --- 59,99 ---- The most important change in Python 2.0 may not be to the code at all, ! but to how Python is developed: in May 2000 the Python developers ! began using the tools made available by SourceForge for storing ! source code, tracking bug reports, and managing the queue of patch ! submissions. To report bugs or submit patches for Python 2.0, use the ! bug tracking and patch manager tools available from Python's project ! page, located at \url{http://sourceforge.net/projects/python/}. ! ! The most important of the services now hosted at SourceForge is the ! Python CVS tree, the version-controlled repository containing the ! source code for Python. Previously, there were roughly 7 or so people ! who had write access to the CVS tree, and all patches had to be ! inspected and checked in by one of the people on this short list. ! Obviously, this wasn't very scalable. By moving the CVS tree to ! SourceForge, it became possible to grant write access to more people; ! as of September 2000 there were 27 people able to check in changes, a ! fourfold increase. This makes possible large-scale changes that ! wouldn't be attempted if they'd have to be filtered through the small ! group of core developers. For example, one day Peter Schneider-Kamp ! took it into his head to drop K\&R C compatibility and convert the C ! source for Python to ANSI C. After getting approval on the python-dev ! mailing list, he launched into a flurry of checkins that lasted about ! a week, other developers joined in to help, and the job was done. If ! there were only 5 people with write access, probably that task would ! have been viewed as ``nice, but not worth the time and effort needed'' ! and it would never have gotten done. ! ! The shift to using SourceForge's services has resulted in a remarkable ! increase in the speed of development. Patches now get submitted, ! commented on, revised by people other than the original submitter, and ! bounced back and forth between people until the patch is deemed worth ! checking in. This didn't come without a cost: developers now have ! more e-mail to deal with, more mailing lists to follow, and special ! tools had to be written for the new environment. For example, ! SourceForge sends default patch and bug notification e-mail messages ! that are completely unhelpful, so Ka-Ping Yee wrote an HTML ! screen-scraper that sends more useful messages. The ease of adding code caused a few initial growing pains, such as code was checked in before it was ready or without getting clear *************** *** 137,144 **** PEP 225, ``Elementwise/Objectwise Operators''. - To report bugs or submit patches for Python 2.0, use the bug tracking - and patch manager tools available from the SourceForge project page, - at \url{http://sourceforge.net/projects/python/}. - % ====================================================================== \section{Unicode} --- 142,145 ---- *************** *** 1158,1163 **** The authors would like to thank the following people for offering suggestions on drafts of this article: Mark Hammond, Gregg Hauser, ! Fredrik Lundh, Detlef Lannert, Skip Montanaro, Vladimir Marangozov, ! Guido van Rossum, and Neil Schemenauer. \end{document} --- 1159,1164 ---- The authors would like to thank the following people for offering suggestions on drafts of this article: Mark Hammond, Gregg Hauser, ! Fredrik Lundh, Detlef Lannert, Aahz Maruch, Skip Montanaro, Vladimir ! Marangozov, Guido van Rossum, Neil Schemenauer, and Russ Schmidt. \end{document} |
|
From: A.M. K. <aku...@us...> - 2000-10-04 12:38:46
|
Update of /cvsroot/py-howto/pyhowto In directory slayer.i.sourceforge.net:/tmp/cvs-serv3081 Modified Files: rexec.tex Log Message: Code checked with Python 2.0, leading to one change (using pre instead of re) Various minor rewrites Bump version number to 2.0 to match Python's Index: rexec.tex =================================================================== RCS file: /cvsroot/py-howto/pyhowto/rexec.tex,v retrieving revision 1.5 retrieving revision 1.6 diff -C2 -r1.5 -r1.6 *** rexec.tex 1999/12/09 12:58:18 1.5 --- rexec.tex 2000/10/04 12:38:34 1.6 *************** *** 3,7 **** \title{Restricted Execution HOWTO} ! \release{1.1} \author{A.M. Kuchling} --- 3,7 ---- \title{Restricted Execution HOWTO} ! \release{2.0} \author{A.M. Kuchling} *************** *** 122,126 **** The previous line will cause an \code{ImportError} exception to be raised, with an associated string value that reads "untrusted dynamic ! module: socket". Trying to open a file for writing is also forbidden: \begin{verbatim} --- 122,126 ---- The previous line will cause an \code{ImportError} exception to be raised, with an associated string value that reads "untrusted dynamic ! module: _socket". Trying to open a file for writing is also forbidden: \begin{verbatim} *************** *** 144,153 **** \end{verbatim} ! In general, these are modules that can't affect anything outside of the ! executing code; they allow various forms of computation, but don't allow ! operations that change the filesystem or use network connections to ! other machines. (The \code{pcre} module may be unfamiliar; it's an ! internal module used by the \code{re} module; this means that restricted ! code can still perform regular expression matches.) It also restricts the variables and functions that are available from --- 144,154 ---- \end{verbatim} ! In general, these are modules that can't affect anything outside of ! the executing code; they allow various forms of computation, but don't ! allow operations that change the filesystem or use network connections ! to other machines. (The \code{pcre} module may be unfamiliar. It's ! an internal module used by the \code{pre} module, which is the module ! that should be used by restricted code to perform regular expression ! matches.) It also restricts the variables and functions that are available from *************** *** 237,242 **** \begin{verbatim} >>> class C: ! .... def f(self): print "Hi!" ! .... \end{verbatim} --- 238,243 ---- \begin{verbatim} >>> class C: ! ... def f(self): print "Hi!" ! ... \end{verbatim} *************** *** 287,292 **** doing this, since \code{g} will be executed without restrictions; you have to be sure that \code{g} is a function that can't be used to do ! any damage. (Or an instance with no methods that do anything ! dangerous. Or a module containing no dangerous functions. You get the idea.) --- 288,293 ---- doing this, since \code{g} will be executed without restrictions; you have to be sure that \code{g} is a function that can't be used to do ! any damage. (Or is an instance with no methods that do anything ! dangerous. Or is a module containing no dangerous functions. You get the idea.) *************** *** 297,301 **** raised by restricted code; they'll be propagated up the call stack until a \code{try...except} statement is found that catches it. If ! none is found, the interpreter will print a traceback and exit, which is its usual behaviour. To prevent untrusted code from terminating the program, you should surround calls to \code{r_exec()}, --- 298,302 ---- raised by restricted code; they'll be propagated up the call stack until a \code{try...except} statement is found that catches it. If ! no exception handler is found, the interpreter will print a traceback and exit, which is its usual behaviour. To prevent untrusted code from terminating the program, you should surround calls to \code{r_exec()}, *************** *** 459,463 **** \end{verbatim} ! \section{Customizing the Restricted Environment} Often you'll wish to customize the restricted environment in various --- 460,464 ---- \end{verbatim} ! \subsection{Modifying Built-ins} Often you'll wish to customize the restricted environment in various *************** *** 522,527 **** \end{verbatim} ! Obviously, a less trivial function could import modules using HTTP or ! whatever. \section{References} --- 523,527 ---- \end{verbatim} ! Obviously, a less trivial function could import modules using HTTP, or do something else of interest. \section{References} *************** *** 566,569 **** --- 566,572 ---- Mar. 16, 1998: Made some revisions suggested by Jeff Rush. Some minor changes and clarifications, and a sizable section on exceptions added. + + Oct. 4, 2000: Checked with Python 2.0. Minor rewrites and fixes made. + Version number increased to 2.0. \end{document} |
|
From: A.M. K. <aku...@us...> - 2000-10-04 12:37:07
|
Update of /cvsroot/py-howto/pyhowto In directory slayer.i.sourceforge.net:/tmp/cvs-serv2057 Modified Files: regex-to-re.tex Log Message: Bumped version number to match Python's Index: regex-to-re.tex =================================================================== RCS file: /cvsroot/py-howto/pyhowto/regex-to-re.tex,v retrieving revision 1.3 retrieving revision 1.4 diff -C2 -r1.3 -r1.4 *** regex-to-re.tex 1999/12/09 12:58:18 1.3 --- regex-to-re.tex 2000/10/04 12:37:03 1.4 *************** *** 3,7 **** \title{regex-to-re HOWTO} ! \release{1.0} \author{A.M. Kuchling} --- 3,7 ---- \title{regex-to-re HOWTO} ! \release{2.0} \author{A.M. Kuchling} |
|
From: A.M. K. <aku...@us...> - 2000-09-27 02:49:27
|
Update of /cvsroot/py-howto/pyhowto In directory slayer.i.sourceforge.net:/tmp/cvs-serv21317 Modified Files: python-2.0.tex Log Message: Fix double negative spotted by ma...@mo... Index: python-2.0.tex =================================================================== RCS file: /cvsroot/py-howto/pyhowto/python-2.0.tex,v retrieving revision 1.33 retrieving revision 1.34 diff -C2 -r1.33 -r1.34 *** python-2.0.tex 2000/09/27 02:36:10 1.33 --- python-2.0.tex 2000/09/27 02:49:24 1.34 *************** *** 76,81 **** joined in to help, and the job was done. If there were only 5 people with write access, probably that task would have been viewed as ! ``nice, but not worth the time and effort needed'' and it wouldn't ! never have been done. SourceForge also provides tools for tracking bug and patch --- 76,81 ---- joined in to help, and the job was done. If there were only 5 people with write access, probably that task would have been viewed as ! ``nice, but not worth the time and effort needed'' and it would ! never have gotten done. SourceForge also provides tools for tracking bug and patch |
|
From: A.M. K. <aku...@us...> - 2000-09-27 02:36:15
|
Update of /cvsroot/py-howto/pyhowto In directory slayer.i.sourceforge.net:/tmp/cvs-serv8395 Modified Files: python-2.0.tex Log Message: Added a section describing the new development process. Part of it comes from two comp.lang.tcl postings of mine, with much rewriting and expansion of the material. Note that 2.0 will be released in the autumn, not the summer. Index: python-2.0.tex =================================================================== RCS file: /cvsroot/py-howto/pyhowto/python-2.0.tex,v retrieving revision 1.32 retrieving revision 1.33 diff -C2 -r1.32 -r1.33 *** python-2.0.tex 2000/09/27 01:33:41 1.32 --- python-2.0.tex 2000/09/27 02:36:10 1.33 *************** *** 19,23 **** A new release of Python, version 2.0, will be released some time this ! summer. Beta versions are already available from \url{http://www.pythonlabs.com/products/python2.0/}. This article covers the exciting new features in 2.0, highlights some other useful --- 19,23 ---- A new release of Python, version 2.0, will be released some time this ! autumn. Beta versions are already available from \url{http://www.pythonlabs.com/products/python2.0/}. This article covers the exciting new features in 2.0, highlights some other useful *************** *** 54,57 **** --- 54,143 ---- described in this document are only in 2.0, because a lot of work was done between May and September. + + % ====================================================================== + \section{New Development Process} + + The most important change in Python 2.0 may not be to the code at all, + but to how Python is developed. + + In May of 2000, the Python CVS tree was moved to SourceForge. + Previously, there were roughly 7 or so people who had write access to + the CVS tree, and all patches had to be inspected and checked in by + one of the people on this short list. Obviously, this wasn't very + scalable. By moving the CVS tree to SourceForge, it became possible + to grant write access to more people; as of September 2000 there were + 27 people able to check in changes, a fourfold increase. This makes + possible large-scale changes that wouldn't be attempted if they'd have + to be filtered through the small group of core developers. For + example, one day Peter Schneider-Kamp took it into his head to drop + K\&R C compatibility and convert the C source for Python to ANSI + C. After getting approval on the python-dev mailing list, he launched + into a flurry of checkins that lasted about a week, other developers + joined in to help, and the job was done. If there were only 5 people + with write access, probably that task would have been viewed as + ``nice, but not worth the time and effort needed'' and it wouldn't + never have been done. + + SourceForge also provides tools for tracking bug and patch + submissions, and in combination with the public CVS tree, they've + resulted in a remarkable increase in the speed of development. + Patches now get submitted, commented on, revised by people other than + the original submitter, and bounced back and forth between people + until the patch is deemed worth checking in. This didn't come without + a cost: developers now have more e-mail to deal with, more mailing + lists to follow, and special tools had to be written for the new + environment. For example, SourceForge sends default patch and bug + notification e-mail messages that are completely unhelpful, so Ka-Ping + Yee wrote an HTML screen-scraper that sends more useful messages. + + The ease of adding code caused a few initial growing pains, such as + code was checked in before it was ready or without getting clear + agreement from the developer group. The approval process that has + emerged is somewhat similar to that used by the Apache group. + Developers can vote +1, +0, -0, or -1 on a patch; +1 and -1 denote + acceptance or rejection, while +0 and -0 mean the developer is mostly + indifferent to the change, though with a slight positive or negative + slant. The most significant change from the Apache model is that + Guido van Rossum, who has Benevolent Dictator For Life status, can + ignore the votes of the other developers and approve or reject a + change, effectively giving him a +Infinity / -Infinity vote. + + Producing an actual patch is the last step in adding a new feature, + and is usually easy compared to the earlier task of coming up with a + good design. Discussions of new features can often explode into + lengthy mailing list threads, making the discussion hard to follow, + and no one can read every posting to python-dev. Therefore, a + relatively formal process has been set up to write Python Enhancement + Proposals (PEPs), modelled on the Internet RFC process. PEPs are + draft documents that describe a proposed new feature, and are + continually revised until the community reaches a consensus, either + accepting or rejecting the proposal. Quoting from the introduction to + PEP 1, ``PEP Purpose and Guidelines'': + + \begin{quotation} + PEP stands for Python Enhancement Proposal. A PEP is a design + document providing information to the Python community, or + describing a new feature for Python. The PEP should provide a + concise technical specification of the feature and a rationale for + the feature. + + We intend PEPs to be the primary mechanisms for proposing new + features, for collecting community input on an issue, and for + documenting the design decisions that have gone into Python. The + PEP author is responsible for building consensus within the + community and documenting dissenting opinions. + \end{quotation} + + Read the rest of PEP 1 for the details of the PEP editorial process, + style, and format. PEPs are kept in the Python CVS tree on + SourceForge, though they're not part of the Python 2.0 distribution, + and are also available in HTML form from + \url{http://python.sourceforge.net/peps/}. As of September 2000, + there are 25 PEPS, ranging from PEP 201, ``Lockstep Iteration'', to + PEP 225, ``Elementwise/Objectwise Operators''. + + To report bugs or submit patches for Python 2.0, use the bug tracking + and patch manager tools available from the SourceForge project page, + at \url{http://sourceforge.net/projects/python/}. % ====================================================================== |
|
From: A.M. K. <aku...@us...> - 2000-09-27 01:33:45
|
Update of /cvsroot/py-howto/pyhowto In directory slayer.i.sourceforge.net:/tmp/cvs-serv10632 Modified Files: python-2.0.tex Log Message: Wrote text for features added between 2.0b1 and b2. Minor rewrites, and added the CVS ID in a comment. Index: python-2.0.tex =================================================================== RCS file: /cvsroot/py-howto/pyhowto/python-2.0.tex,v retrieving revision 1.31 retrieving revision 1.32 diff -C2 -r1.31 -r1.32 *** python-2.0.tex 2000/09/27 01:01:18 1.31 --- python-2.0.tex 2000/09/27 01:33:41 1.32 *************** *** 1,4 **** --- 1,6 ---- \documentclass{howto} + % $Id$ + \title{What's New in Python 2.0} \release{0.05} *************** *** 115,118 **** --- 117,127 ---- case of any problems. + \item The \keyword{exec} statement, and various built-ins such as + \code{eval()}, \code{getattr()}, and \code{setattr()} will also + accept Unicode strings as well as regular strings. (It's possible + that the process of fixing this missed some built-ins; if you find a + built-in function that accepts strings but doesn't accept Unicode + strings at all, please report it as a bug.) + \end{itemize} *************** *** 142,146 **** \var{length})}, consisting of the resulting Unicode string \var{ustring} and the integer \var{length} telling how much of the ! string was consumed. \item \var{stream_reader} is a class that supports decoding input from --- 151,155 ---- \var{length})}, consisting of the resulting Unicode string \var{ustring} and the integer \var{length} telling how much of the ! 8-bit string was consumed. \item \var{stream_reader} is a class that supports decoding input from *************** *** 671,676 **** to; \code{3L * 'abc'} produces 'abcabcabc', and \code{ (0,1,2,3)[2L:4L]} produces (2,3). Long integers can also be used in ! various new places where previously only integers were accepted, such ! as in the \method{seek()} method of file objects. The subtlest long integer change of all is that the \function{str()} --- 680,688 ---- to; \code{3L * 'abc'} produces 'abcabcabc', and \code{ (0,1,2,3)[2L:4L]} produces (2,3). Long integers can also be used in ! various contexts where previously only integers were accepted, such ! as in the \method{seek()} method of file objects, and in the formats ! supported by the \verb|%| operator (\verb|%d|, \verb|%i|, \verb|%x|, ! etc.). For example, \code{"\%d" \% 2L**64} will produce the string ! \samp{18446744073709551616}. The subtlest long integer change of all is that the \function{str()} *************** *** 771,777 **** bytecode, limiting the size of source files. In particular, this affected the maximum size of literal lists and dictionaries in Python ! source; occasionally people who are generating Python code would run into this limit. ! A patch by Charles G. Waldman raises the limit from \verb|2^16| to \verb|2^{32}|. ! % ====================================================================== --- 783,802 ---- bytecode, limiting the size of source files. In particular, this affected the maximum size of literal lists and dictionaries in Python ! source; occasionally people who are generating Python code would run ! into this limit. A patch by Charles G. Waldman raises the limit from ! \verb|2^16| to \verb|2^{32}|. ! ! Three new convenience functions intended for adding constants to a ! module's dictionary at module initialization time were added: ! \function{PyModule_AddObject()}, \function{PyModule_AddIntConstant()}, ! and \function{PyModule_AddStringConstant()}. Each of these functions ! takes a module object, a null-terminated C string containing the name ! to be added, and a third argument for the value to be assigned to the ! name. This third argument is, respectively, a Python object, a C ! long, or a C string. ! ! A wrapper API was added for Unix-style signal handlers. ! \function{PyOS_getsig()} gets a signal handler and ! \function{PyOS_setsig()} will set a new handler. % ====================================================================== *************** *** 783,788 **** had to go through an arduous ritual of editing Makefiles and configuration files, which only really work on Unix and leave Windows ! and MacOS unsupported. Software users faced wildly differing ! installation instructions The SIG for distribution utilities, shepherded by Greg Ward, has --- 808,815 ---- had to go through an arduous ritual of editing Makefiles and configuration files, which only really work on Unix and leave Windows ! and MacOS unsupported. Python users faced wildly differing ! installation instructions which varied between different extension ! packages, which made adminstering a Python installation something of a ! chore. The SIG for distribution utilities, shepherded by Greg Ward, has |
|
From: A.M. K. <aku...@us...> - 2000-09-27 01:01:21
|
Update of /cvsroot/py-howto/pyhowto In directory slayer.i.sourceforge.net:/tmp/cvs-serv7693 Modified Files: python-2.0.tex Log Message: Fixed error in explanation of codec decode_func pointed out by Gregg Hauser, and rewrote paragraph a bit. Index: python-2.0.tex =================================================================== RCS file: /cvsroot/py-howto/pyhowto/python-2.0.tex,v retrieving revision 1.30 retrieving revision 1.31 diff -C2 -r1.30 -r1.31 *** python-2.0.tex 2000/09/25 14:40:15 1.30 --- python-2.0.tex 2000/09/27 01:01:18 1.31 *************** *** 138,145 **** how much of the Unicode string was converted. ! \item \var{decode_func} is the mirror of \var{encode_func}, ! taking a Unicode string and ! returns a 2-tuple \code{(\var{ustring}, \var{length})} containing a Unicode string ! and \var{length} telling you how much of the string was consumed. \item \var{stream_reader} is a class that supports decoding input from --- 138,146 ---- how much of the Unicode string was converted. ! \item \var{decode_func} is the opposite of \var{encode_func}, taking ! an 8-bit string and returning a 2-tuple \code{(\var{ustring}, ! \var{length})}, consisting of the resulting Unicode string ! \var{ustring} and the integer \var{length} telling how much of the ! string was consumed. \item \var{stream_reader} is a class that supports decoding input from *************** *** 1043,1049 **** The authors would like to thank the following people for offering ! suggestions on drafts of this article: Mark Hammond, Fredrik Lundh, ! Detlef Lannert, Skip Montanaro, Vladimir Marangozov, Guido van Rossum, ! and Neil Schemenauer. \end{document} --- 1044,1050 ---- The authors would like to thank the following people for offering ! suggestions on drafts of this article: Mark Hammond, Gregg Hauser, ! Fredrik Lundh, Detlef Lannert, Skip Montanaro, Vladimir Marangozov, ! Guido van Rossum, and Neil Schemenauer. \end{document} |
|
From: A.M. K. <aku...@us...> - 2000-09-25 14:40:19
|
Update of /cvsroot/py-howto/pyhowto In directory slayer.i.sourceforge.net:/tmp/cvs-serv16875 Modified Files: python-2.0.tex Log Message: Update URL for Python 2.0 Index: python-2.0.tex =================================================================== RCS file: /cvsroot/py-howto/pyhowto/python-2.0.tex,v retrieving revision 1.29 retrieving revision 1.30 diff -C2 -r1.29 -r1.30 *** python-2.0.tex 2000/09/06 17:58:49 1.29 --- python-2.0.tex 2000/09/25 14:40:15 1.30 *************** *** 18,22 **** A new release of Python, version 2.0, will be released some time this summer. Beta versions are already available from ! \url{http://www.pythonlabs.com/tech/python2.html}. This article covers the exciting new features in 2.0, highlights some other useful changes, and points out a few incompatible changes that may require --- 18,22 ---- A new release of Python, version 2.0, will be released some time this summer. Beta versions are already available from ! \url{http://www.pythonlabs.com/products/python2.0/}. This article covers the exciting new features in 2.0, highlights some other useful changes, and points out a few incompatible changes that may require |
|
From: Fred L. D. <fd...@us...> - 2000-09-07 01:43:54
|
Update of /cvsroot/py-howto/pyhowto In directory slayer.i.sourceforge.net:/tmp/cvs-serv1562 Modified Files: Makefile Log Message: If the output directories do not exist, create them. Index: Makefile =================================================================== RCS file: /cvsroot/py-howto/pyhowto/Makefile,v retrieving revision 1.3 retrieving revision 1.4 diff -C2 -r1.3 -r1.4 *** Makefile 2000/08/16 03:39:51 1.3 --- Makefile 2000/09/07 01:43:51 1.4 *************** *** 6,10 **** python-2.0.tex ! MKHOWTO=../tools/mkhowto --- 6,10 ---- python-2.0.tex ! MKHOWTO=mkhowto *************** *** 19,23 **** tar -cvf - $(HOWTOS) dvi pdf ps html | gzip -9 -c >dist-howto.tgz ! DVI: for i in $(HOWTOS) ; do \ $(MKHOWTO) --dvi $$i ;\ --- 19,23 ---- tar -cvf - $(HOWTOS) dvi pdf ps html | gzip -9 -c >dist-howto.tgz ! DVI: dvi for i in $(HOWTOS) ; do \ $(MKHOWTO) --dvi $$i ;\ *************** *** 26,29 **** --- 26,32 ---- done + dvi: + mkdir dvi + HTML: for i in $(HOWTOS) ; do \ *************** *** 33,37 **** done ! PDF: for i in $(HOWTOS) ; do \ $(MKHOWTO) --pdf $$i ;\ --- 36,40 ---- done ! PDF: pdf for i in $(HOWTOS) ; do \ $(MKHOWTO) --pdf $$i ;\ *************** *** 39,44 **** mv $$base.pdf pdf/ ;\ done ! PS: for i in $(HOWTOS) ; do \ $(MKHOWTO) --ps $$i ;\ --- 42,50 ---- mv $$base.pdf pdf/ ;\ done + + pdf: + mkdir pdf ! PS: ps for i in $(HOWTOS) ; do \ $(MKHOWTO) --ps $$i ;\ *************** *** 46,49 **** --- 52,58 ---- mv $$base.ps ps/ ;\ done + + ps: + mkdir ps clean: |
|
From: Fred L. D. <fd...@us...> - 2000-09-07 01:42:45
|
Update of /cvsroot/py-howto/pyhowto In directory slayer.i.sourceforge.net:/tmp/cvs-serv567 Added Files: .cvsignore Log Message: Let's not be quite so noisy about the output directories when doing a "cvs up". --- NEW FILE --- dvi html pdf ps |
|
From: A.M. K. <aku...@us...> - 2000-09-06 17:58:52
|
Update of /cvsroot/py-howto/pyhowto In directory slayer.i.sourceforge.net:/tmp/cvs-serv18162 Modified Files: python-2.0.tex Log Message: Add new section "What About Python 1.6?" Document some things in the 2.0 NEWS files that should be mentioned here. Index: python-2.0.tex =================================================================== RCS file: /cvsroot/py-howto/pyhowto/python-2.0.tex,v retrieving revision 1.28 retrieving revision 1.29 diff -C2 -r1.28 -r1.29 *** python-2.0.tex 2000/09/06 12:30:25 1.28 --- python-2.0.tex 2000/09/06 17:58:49 1.29 *************** *** 31,34 **** --- 31,57 ---- % ====================================================================== + \section{What About Python 1.6?} + + Python 1.6 can be thought of as the Contractual Obligations Python + release. After the core development team left CNRI in May 2000, CNRI + requested that a 1.6 release be created, containing all the work on + Python that had been performed at CNRI. Python 1.6 therefore + represents the state of the CVS tree as of May 2000, with the most + significant new feature being Unicode support. Development continued + after May, of course, so the 1.6 tree received a few fixes to ensure + that it's forward-compatible with Python 2.0. 1.6 is therefore part + of Python's evolution, and not a side branch. + + So, should you take much interest in Python 1.6? Probably not. The + 1.6final and 2.0beta1 releases were made on the same day (September 5, + 2000), the plan being to finalize Python 2.0 within a month or so. If + you have applications to maintain, there seems little point in + breaking things by moving to 1.6, fixing them, and then having another + round of breakage within a month by moving to 2.0; you're better off + just going straight to 2.0. Most of the really interesting features + described in this document are only in 2.0, because a lot of work was + done between May and September. + + % ====================================================================== \section{Unicode} *************** *** 529,532 **** --- 552,560 ---- \end{verbatim} + Two new exceptions, \exception{TabError} and + \exception{IndentationError}, have been introduced. They're both + subclasses of \exception{SyntaxError}, and are raised when Python code + is found to be improperly indented. + \subsection{Changes to Built-in Functions} *************** *** 570,573 **** --- 598,609 ---- can be reduced to a single \code{return dict.setdefault(key, [])} statement. + The interpreter sets a maximum recursion depth in order to catch + runaway recursion before filling the C stack and causing a core dump + or GPF.. Previously this limit was fixed when you compiled Python, + but in 2.0 the maximum recursion depth can be read and modified using + \function{sys.getrecursionlimit} and \function{sys.setrecursionlimit}. + The default value is 1000, and a rough maximum value for a given + platform can be found by running a new script, + \file{Misc/find_recursionlimit.py}. % ====================================================================== *************** *** 576,581 **** New Python releases try hard to be compatible with previous releases, and the record has been pretty good. However, some changes are ! considered useful enough, often fixing initial design decisions that ! turned to be actively mistaken, that breaking backward compatibility can't always be avoided. This section lists the changes in Python 2.0 that may cause old Python code to break. --- 612,617 ---- New Python releases try hard to be compatible with previous releases, and the record has been pretty good. However, some changes are ! considered useful enough, usually because they fix initial design decisions that ! turned out to be actively mistaken, that breaking backward compatibility can't always be avoided. This section lists the changes in Python 2.0 that may cause old Python code to break. *************** *** 614,617 **** --- 650,663 ---- it \emph{will} be tightened up again in a future Python version. + The \code{\e x} escape in string literals now takes exactly 2 hex + digits. Previously it would consume all the hex digits following the + 'x' and take the lowest 8 bits of the result, so \code{\e x123456} was + equivalent to \code{\e x56}. + + The \exception{AttributeError} exception has a more friendly error message, + whose text will be something like \code{'Spam' instance has no attribute 'eggs'}. + Previously the error message was just the missing attribute name \code{eggs}, and + code written to take advantage of this fact will break in 2.0. + Some work has been done to make integers and long integers a bit more interchangeable. In 1.5.2, large-file support was added for Solaris, *************** *** 720,723 **** --- 766,776 ---- requires an ANSI C compiler, and can no longer be done using a compiler that only supports K\&R C. + + Previously the Python virtual machine used 16-bit numbers in its + bytecode, limiting the size of source files. In particular, this + affected the maximum size of literal lists and dictionaries in Python + source; occasionally people who are generating Python code would run into this limit. + A patch by Charles G. Waldman raises the limit from \verb|2^16| to \verb|2^{32}|. + % ====================================================================== |
|
From: A.M. K. <aku...@us...> - 2000-09-06 12:30:29
|
Update of /cvsroot/py-howto/pyhowto In directory slayer.i.sourceforge.net:/tmp/cvs-serv28828 Modified Files: python-2.0.tex Log Message: Removed mention of the winreg module, since it was deleted from 2.0b1 Index: python-2.0.tex =================================================================== RCS file: /cvsroot/py-howto/pyhowto/python-2.0.tex,v retrieving revision 1.27 retrieving revision 1.28 diff -C2 -r1.27 -r1.28 *** python-2.0.tex 2000/09/04 17:59:27 1.27 --- python-2.0.tex 2000/09/06 12:30:25 1.28 *************** *** 915,925 **** and adapted for the standard library by Fred.) ! \item{\module{winreg} and \module{_winreg}:} An interface to the Windows registry. \module{_winreg} is an adaptation of functions that have been part of PythonWin since 1995, but has now been added to the core ! distribution, and enhanced to support Unicode. \module{winreg} is an ! object-oriented API on top of the \module{_winreg} module. ! \module{_winreg} was written by Bill Tutt and Mark Hammond, and \module{winreg} ! was designed by Thomas Heller and implemented by Paul Prescod. \item{\module{zipfile}:} A module for reading and writing ZIP-format --- 915,923 ---- and adapted for the standard library by Fred.) ! \item{\module{_winreg}:} An interface to the Windows registry. \module{_winreg} is an adaptation of functions that have been part of PythonWin since 1995, but has now been added to the core ! distribution, and enhanced to support Unicode. ! \module{_winreg} was written by Bill Tutt and Mark Hammond. \item{\module{zipfile}:} A module for reading and writing ZIP-format |
|
From: A.M. K. <aku...@us...> - 2000-09-04 17:59:34
|
Update of /cvsroot/py-howto/pyhowto In directory slayer.i.sourceforge.net:/tmp/cvs-serv20875 Modified Files: python-2.0.tex Log Message: Various corrections pointed out by Detlef Lannert Index: python-2.0.tex =================================================================== RCS file: /cvsroot/py-howto/pyhowto/python-2.0.tex,v retrieving revision 1.26 retrieving revision 1.27 diff -C2 -r1.26 -r1.27 *** python-2.0.tex 2000/08/30 12:55:42 1.26 --- python-2.0.tex 2000/09/04 17:59:27 1.27 *************** *** 2,6 **** \title{What's New in Python 2.0} ! \release{0.04} \author{A.M. Kuchling and Moshe Zadka} \authoraddress{\email{am...@bi...}, \email{mo...@ma...} } --- 2,6 ---- \title{What's New in Python 2.0} ! \release{0.05} \author{A.M. Kuchling and Moshe Zadka} \authoraddress{\email{am...@bi...}, \email{mo...@ma...} } *************** *** 82,87 **** \item \code{ord(\var{u})}, where \var{u} is a 1-character regular or Unicode string, returns the number of the character as an integer. ! \item \code{unicode(\var{string}, \optional{\var{encoding},} ! \optional{\var{errors}} ) } creates a Unicode string from an 8-bit string. \code{encoding} is a string naming the encoding to use. The \code{errors} parameter specifies the treatment of characters that --- 82,87 ---- \item \code{ord(\var{u})}, where \var{u} is a 1-character regular or Unicode string, returns the number of the character as an integer. ! \item \code{unicode(\var{string} \optional{, \var{encoding}} ! \optional{, \var{errors}} ) } creates a Unicode string from an 8-bit string. \code{encoding} is a string naming the encoding to use. The \code{errors} parameter specifies the treatment of characters that *************** *** 152,156 **** \begin{verbatim} ! input = UTF8_streamread( open( '/tmp/output', 'rb') ) print repr(input.read()) input.close() --- 152,156 ---- \begin{verbatim} ! input = UTF8_streamreader( open( '/tmp/output', 'rb') ) print repr(input.read()) input.close() *************** *** 273,281 **** Augmented assignment operators, another long-requested feature, have ! been added to Python 2.0. Augmented assignment operators include ! \code{+=}, \code{-=}, \code{*=}, and so forth. For example, the ! statement \code{a += 2} increments the value of the variable \code{a} ! by 2, equivalent to the slightly lengthier ! \code{a = a + 2}. The full list of supported assignment operators is \code{+=}, --- 273,280 ---- Augmented assignment operators, another long-requested feature, have ! been added to Python 2.0. Augmented assignment operators include ! \code{+=}, \code{-=}, \code{*=}, and so forth. For example, the ! statement \code{a += 2} increments the value of the variable ! \code{a} by 2, equivalent to the slightly lengthier \code{a = a + 2}. The full list of supported assignment operators is \code{+=}, *************** *** 313,317 **** Until now string-manipulation functionality was in the \module{string} ! Python module, which was usually a front-end for the \module{strop} module written in C. The addition of Unicode posed a difficulty for the \module{strop} module, because the functions would all need to be --- 312,316 ---- Until now string-manipulation functionality was in the \module{string} ! module, which was usually a front-end for the \module{strop} module written in C. The addition of Unicode posed a difficulty for the \module{strop} module, because the functions would all need to be *************** *** 446,455 **** The \keyword{print} statement can now have its output directed to a ! file-like object by following the \keyword{print} with \code{>> ! \var{fileobj}}, similar to the redirection operator in Unix shells. Previously you'd either have to use the \method{write()} method of the file-like object, which lacks the convenience and simplicity of ! \keyword{print}, or you could assign a new value to \code{sys.stdout} ! and then restore the old value. For sending output to standard error, it's much easier to write this: --- 445,454 ---- The \keyword{print} statement can now have its output directed to a ! file-like object by following the \keyword{print} with ! \verb|>> file|, similar to the redirection operator in Unix shells. Previously you'd either have to use the \method{write()} method of the file-like object, which lacks the convenience and simplicity of ! \keyword{print}, or you could assign a new value to ! \code{sys.stdout} and then restore the old value. For sending output to standard error, it's much easier to write this: *************** *** 536,542 **** contains the i-th element from each of the argument sequences. The difference between \function{zip()} and \code{map(None, \var{seq1}, ! \var{seq2})} is that \function{map()} raises an error if the sequences ! aren't all of the same length, while \function{zip()} truncates the ! returned list to the length of the shortest argument sequence. The \function{int()} and \function{long()} functions now accept an --- 535,542 ---- contains the i-th element from each of the argument sequences. The difference between \function{zip()} and \code{map(None, \var{seq1}, ! \var{seq2})} is that \function{map()} pads the sequences with ! \code{None} if the sequences aren't all of the same length, while ! \function{zip()} truncates the returned list to the length of the ! shortest argument sequence. The \function{int()} and \function{long()} functions now accept an *************** *** 552,556 **** \code{sys.version_info} would be \code{(2, 0, 1, 'beta', 1)}. \var{level} is a string such as \code{"alpha"}, \code{"beta"}, or ! \code{""} for a final release. Dictionaries have an odd new method, \method{setdefault(\var{key}, --- 552,556 ---- \code{sys.version_info} would be \code{(2, 0, 1, 'beta', 1)}. \var{level} is a string such as \code{"alpha"}, \code{"beta"}, or ! \code{"final"} for a final release. Dictionaries have an odd new method, \method{setdefault(\var{key}, *************** *** 610,614 **** argument form, many people wrote code which would break with the stricter checking. GvR backed out the changes in the face of public ! reaction, so for the\module{socket} module, the documentation was fixed and the multiple argument form is simply marked as deprecated; it \emph{will} be tightened up again in a future Python version. --- 610,614 ---- argument form, many people wrote code which would break with the stricter checking. GvR backed out the changes in the face of public ! reaction, so for the \module{socket} module, the documentation was fixed and the multiple argument form is simply marked as deprecated; it \emph{will} be tightened up again in a future Python version. *************** *** 632,638 **** wanted to print long integers that looked just like regular integers, since they had to go out of their way to chop off the character. This ! is no longer a problem in 2.0, but code which assumes the 'L' is ! there, and does \code{str(longval)[:-1]} will now lose the final ! digit. Taking the \function{repr()} of a float now uses a different --- 632,637 ---- wanted to print long integers that looked just like regular integers, since they had to go out of their way to chop off the character. This ! is no longer a problem in 2.0, but code which does \code{str(longval)[:-1]} and assumes the 'L' is there, will now lose ! the final digit. Taking the \function{repr()} of a float now uses a different *************** *** 641,645 **** \function{str()} uses \code{\%.12g} as before. The effect is that \function{repr()} may occasionally show more decimal places than ! \function{str()}, for numbers For example, the number 8.1 can't be represented exactly in binary, so \code{repr(8.1)} is \code{'8.0999999999999996'}, while str(8.1) is --- 640,644 ---- \function{str()} uses \code{\%.12g} as before. The effect is that \function{repr()} may occasionally show more decimal places than ! \function{str()}, for certain numbers. For example, the number 8.1 can't be represented exactly in binary, so \code{repr(8.1)} is \code{'8.0999999999999996'}, while str(8.1) is *************** *** 728,732 **** was no way to figure out automatically where Python is installed, or what compiler options to use for extension modules. Software authors ! had to go through an ardous ritual of editing Makefiles and configuration files, which only really work on Unix and leave Windows and MacOS unsupported. Software users faced wildly differing --- 727,731 ---- was no way to figure out automatically where Python is installed, or what compiler options to use for extension modules. Software authors ! had to go through an arduous ritual of editing Makefiles and configuration files, which only really work on Unix and leave Windows and MacOS unsupported. Software users faced wildly differing *************** *** 836,841 **** 8.3, and support for the older 7.x versions has been dropped. The Tkinter module now supports displaying Unicode strings in Tk widgets. ! Also, Fredrik Lundh contributed an optimization which make operations ! like \code{create_line} and \code{create_polygon} are much faster, especially when using lots of coordinates. --- 835,840 ---- 8.3, and support for the older 7.x versions has been dropped. The Tkinter module now supports displaying Unicode strings in Tk widgets. ! Also, Fredrik Lundh contributed an optimization which makes operations ! like \code{create_line} and \code{create_polygon} much faster, especially when using lots of coordinates. *************** *** 896,905 **** \item{\module{robotparser}:} Parse a \file{robots.txt} file, which is used for writing Web spiders that politely avoid certain areas of a ! Web site. The parser accepts the contents of a \file{robots.txt} file builds a set of rules from it, and can then answer questions about the fetchability of a given URL. (Contributed by Skip Montanaro.) \item{\module{tabnanny}:} A module/script to ! checks Python source code for ambiguous indentation. (Contributed by Tim Peters.) --- 895,904 ---- \item{\module{robotparser}:} Parse a \file{robots.txt} file, which is used for writing Web spiders that politely avoid certain areas of a ! Web site. The parser accepts the contents of a \file{robots.txt} file, builds a set of rules from it, and can then answer questions about the fetchability of a given URL. (Contributed by Skip Montanaro.) \item{\module{tabnanny}:} A module/script to ! check Python source code for ambiguous indentation. (Contributed by Tim Peters.) *************** *** 993,998 **** The authors would like to thank the following people for offering ! suggestions on drafts of this article: Fredrik Lundh, Skip ! Montanaro, Vladimir Marangozov, Guido van Rossum, Neil Schemenauer. \end{document} --- 992,998 ---- The authors would like to thank the following people for offering ! suggestions on drafts of this article: Mark Hammond, Fredrik Lundh, ! Detlef Lannert, Skip Montanaro, Vladimir Marangozov, Guido van Rossum, ! and Neil Schemenauer. \end{document} |
|
From: A.M. K. <aku...@us...> - 2000-08-30 12:55:45
|
Update of /cvsroot/py-howto/pyhowto In directory slayer.i.sourceforge.net:/tmp/cvs-serv31470 Modified Files: python-2.0.tex Log Message: Fix markup error Index: python-2.0.tex =================================================================== RCS file: /cvsroot/py-howto/pyhowto/python-2.0.tex,v retrieving revision 1.25 retrieving revision 1.26 diff -C2 -r1.25 -r1.26 *** python-2.0.tex 2000/08/30 00:51:02 1.25 --- python-2.0.tex 2000/08/30 12:55:42 1.26 *************** *** 281,285 **** The full list of supported assignment operators is \code{+=}, \code{-=}, \code{*=}, \code{/=}, \code{\%=}, \code{**=}, \code{\&=}, ! \code{|=}, \code{^=}, \code{>>=}, and \code{<<=}. Python classes can override the augmented assignment operators by defining methods named \method{__iadd__}, \method{__isub__}, etc. For example, the following --- 281,285 ---- The full list of supported assignment operators is \code{+=}, \code{-=}, \code{*=}, \code{/=}, \code{\%=}, \code{**=}, \code{\&=}, ! \code{|=}, \verb|^=|, \code{>>=}, and \code{<<=}. Python classes can override the augmented assignment operators by defining methods named \method{__iadd__}, \method{__isub__}, etc. For example, the following |
|
From: A.M. K. <aku...@us...> - 2000-08-30 00:51:06
|
Update of /cvsroot/py-howto/pyhowto In directory slayer.i.sourceforge.net:/tmp/cvs-serv8437 Modified Files: python-2.0.tex Log Message: Removed forgotten text in list comprehensions section (taken from the Haskell description of listcomps and used as inspiration) Rearranged sections (which accounts for much of the size of the diffs) Added section on augmented assignment Mentioned 'print >>file' Broke up the "Core Changes" section into subsections Index: python-2.0.tex =================================================================== RCS file: /cvsroot/py-howto/pyhowto/python-2.0.tex,v retrieving revision 1.24 retrieving revision 1.25 diff -C2 -r1.24 -r1.25 *** python-2.0.tex 2000/08/17 23:37:01 1.24 --- python-2.0.tex 2000/08/30 00:51:02 1.25 *************** *** 262,266 **** \end{verbatim} - The idea of list comprehensions originally comes from the functional programming language Haskell (\url{http://www.haskell.org}). Greg --- 262,265 ---- *************** *** 270,363 **** up-to-date by Skip Montanaro. - - - - A list comprehension has the form [ e | q[1], ..., q[n] ], n>=1, where - the q[i] qualifiers are either - * generators of the form p <- e, where p is a pattern (see Section - 3.17) of type t and e is an expression of type [t] - * guards, which are arbitrary expressions of type Bool - * local bindings that provide new definitions for use in the - generated expression e or subsequent guards and generators. - - % ====================================================================== ! \section{Distutils: Making Modules Easy to Install} ! Before Python 2.0, installing modules was a tedious affair -- there ! was no way to figure out automatically where Python is installed, or ! what compiler options to use for extension modules. Software authors ! had to go through an ardous ritual of editing Makefiles and ! configuration files, which only really work on Unix and leave Windows ! and MacOS unsupported. Software users faced wildly differing ! installation instructions - The SIG for distribution utilities, shepherded by Greg Ward, has - created the Distutils, a system to make package installation much - easier. They form the \module{distutils} package, a new part of - Python's standard library. In the best case, installing a Python - module from source will require the same steps: first you simply mean - unpack the tarball or zip archive, and the run ``\code{python setup.py - install}''. The platform will be automatically detected, the compiler - will be recognized, C extension modules will be compiled, and the - distribution installed into the proper directory. Optional - command-line arguments provide more control over the installation - process, the distutils package offers many places to override defaults - -- separating the build from the install, building or installing in - non-default directories, and more. - - In order to use the Distutils, you need to write a \file{setup.py} - script. For the simple case, when the software contains only .py - files, a minimal \file{setup.py} can be just a few lines long: - - \begin{verbatim} - from distutils.core import setup - setup (name = "foo", version = "1.0", - py_modules = ["module1", "module2"]) - \end{verbatim} - - The \file{setup.py} file isn't much more complicated if the software - consists of a few packages: - \begin{verbatim} ! from distutils.core import setup ! setup (name = "foo", version = "1.0", ! packages = ["package", "package.subpackage"]) \end{verbatim} - - A C extension can be the most complicated case; here's an example taken from - the PyXML package: - \begin{verbatim} - from distutils.core import setup, Extension - - expat_extension = Extension('xml.parsers.pyexpat', - define_macros = [('XML_NS', None)], - include_dirs = [ 'extensions/expat/xmltok', - 'extensions/expat/xmlparse' ], - sources = [ 'extensions/pyexpat.c', - 'extensions/expat/xmltok/xmltok.c', - 'extensions/expat/xmltok/xmlrole.c', - ] - ) - setup (name = "PyXML", version = "0.5.4", - ext_modules =[ expat_extension ] ) - - \end{verbatim} - - The Distutils can also take care of creating source and binary - distributions. The ``sdist'' command, run by ``\code{python setup.py - sdist}', builds a source distribution such as \file{foo-1.0.tar.gz}. - Adding new commands isn't difficult, ``bdist_rpm'' and - ``bdist_wininst'' commands have already been contributed to create an - RPM distribution and a Windows installer for the software, - respectively. Commands to create other distribution formats such as - Debian packages and Solaris \file{.pkg} files are in various stages of - development. - - All this is documented in a new manual, \textit{Distributing Python - Modules}, that joins the basic set of Python documentation. - % ====================================================================== \section{String Methods} --- 269,312 ---- up-to-date by Skip Montanaro. % ====================================================================== ! \section{Augmented Assignment} ! Augmented assignment operators, another long-requested feature, have ! been added to Python 2.0. Augmented assignment operators include ! \code{+=}, \code{-=}, \code{*=}, and so forth. For example, the ! statement \code{a += 2} increments the value of the variable \code{a} ! by 2, equivalent to the slightly lengthier ! \code{a = a + 2}. ! ! The full list of supported assignment operators is \code{+=}, ! \code{-=}, \code{*=}, \code{/=}, \code{\%=}, \code{**=}, \code{\&=}, ! \code{|=}, \code{^=}, \code{>>=}, and \code{<<=}. Python classes can ! override the augmented assignment operators by defining methods named ! \method{__iadd__}, \method{__isub__}, etc. For example, the following ! \class{Number} class stores a number and supports using += to create a ! new instance with an incremented value. \begin{verbatim} ! class Number: ! def __init__(self, value): ! self.value = value ! def __iadd__(self, increment): ! return Number( self.value + increment) ! ! n = Number(5) ! n += 3 ! print n.value \end{verbatim} + The \method{__iadd__} special method is called with the value of the + increment, and should return a new instance with an appropriately + modified value; this return value is bound as the new value of the + variable on the left-hand side. + + Augmented assignment operators were first introduced in the C + programming language, and most C-derived languages, such as + \program{awk}, C++, Java, Perl, and PHP also support them. The augmented + assignment patch was implemented by Thomas Wouters. % ====================================================================== \section{String Methods} *************** *** 385,391 **** \end{verbatim} ! One thing that hasn't changed, April Fools' jokes notwithstanding, is ! that Python strings are immutable. Thus, the string methods return new ! strings, and do not modify the string on which they operate. The old \module{string} module is still around for backwards --- 334,341 ---- \end{verbatim} ! One thing that hasn't changed, a noteworthy April Fools' joke ! notwithstanding, is that Python strings are immutable. Thus, the ! string methods return new strings, and do not modify the string on ! which they operate. The old \module{string} module is still around for backwards *************** *** 468,580 **** cycle collection for Python'' and ``Finalization again''. - - % ====================================================================== - %\section{New XML Code} - - %XXX write this section... - % ====================================================================== ! \section{Porting to 2.0} ! ! New Python releases try hard to be compatible with previous releases, ! and the record has been pretty good. However, some changes are ! considered useful enough, often fixing initial design decisions that ! turned to be actively mistaken, that breaking backward compatibility ! can't always be avoided. This section lists the changes in Python 2.0 ! that may cause old Python code to break. - The change which will probably break the most code is tightening up - the arguments accepted by some methods. Some methods would take - multiple arguments and treat them as a tuple, particularly various - list methods such as \method{.append()} and \method{.insert()}. - In earlier versions of Python, if \code{L} is a list, \code{L.append( - 1,2 )} appends the tuple \code{(1,2)} to the list. In Python 2.0 this - causes a \exception{TypeError} exception to be raised, with the - message: 'append requires exactly 1 argument; 2 given'. The fix is to - simply add an extra set of parentheses to pass both values as a tuple: - \code{L.append( (1,2) )}. - - The earlier versions of these methods were more forgiving because they - used an old function in Python's C interface to parse their arguments; - 2.0 modernizes them to use \function{PyArg_ParseTuple}, the current - argument parsing function, which provides more helpful error messages - and treats multi-argument calls as errors. If you absolutely must use - 2.0 but can't fix your code, you can edit \file{Objects/listobject.c} - and define the preprocessor symbol \code{NO_STRICT_LIST_APPEND} to - preserve the old behaviour; this isn't recommended. - - Some of the functions in the \module{socket} module are still - forgiving in this way. For example, \function{socket.connect( - ('hostname', 25) )} is the correct form, passing a tuple representing - an IP address, but \function{socket.connect( 'hostname', 25 )} also - works. \function{socket.connect_ex()} and \function{socket.bind()} are - similarly easy-going. 2.0alpha1 tightened these functions up, but - because the documentation actually used the erroneous multiple - argument form, many people wrote code which would break with the - stricter checking. GvR backed out the changes in the face of public - reaction, so for the\module{socket} module, the documentation was - fixed and the multiple argument form is simply marked as deprecated; - it \emph{will} be tightened up again in a future Python version. - - Some work has been done to make integers and long integers a bit more - interchangeable. In 1.5.2, large-file support was added for Solaris, - to allow reading files larger than 2Gb; this made the \method{tell()} - method of file objects return a long integer instead of a regular - integer. Some code would subtract two file offsets and attempt to use - the result to multiply a sequence or slice a string, but this raised a - \exception{TypeError}. In 2.0, long integers can be used to multiply - or slice a sequence, and it'll behave as you'd intuitively expect it - to; \code{3L * 'abc'} produces 'abcabcabc', and \code{ - (0,1,2,3)[2L:4L]} produces (2,3). Long integers can also be used in - various new places where previously only integers were accepted, such - as in the \method{seek()} method of file objects. - - The subtlest long integer change of all is that the \function{str()} - of a long integer no longer has a trailing 'L' character, though - \function{repr()} still includes it. The 'L' annoyed many people who - wanted to print long integers that looked just like regular integers, - since they had to go out of their way to chop off the character. This - is no longer a problem in 2.0, but code which assumes the 'L' is - there, and does \code{str(longval)[:-1]} will now lose the final - digit. - - Taking the \function{repr()} of a float now uses a different - formatting precision than \function{str()}. \function{repr()} uses - \code{\%.17g} format string for C's \function{sprintf()}, while - \function{str()} uses \code{\%.12g} as before. The effect is that - \function{repr()} may occasionally show more decimal places than - \function{str()}, for numbers - For example, the number 8.1 can't be represented exactly in binary, so - \code{repr(8.1)} is \code{'8.0999999999999996'}, while str(8.1) is - \code{'8.1'}. - - The \code{-X} command-line option, which turned all standard - exceptions into strings instead of classes, has been removed; the - standard exceptions will now always be classes. The - \module{exceptions} module containing the standard exceptions was - translated from Python to a built-in C module, written by Barry Warsaw - and Fredrik Lundh. - - % Commented out for now -- I don't think anyone will care. - %The pattern and match objects provided by SRE are C types, not Python - %class instances as in 1.5. This means you can no longer inherit from - %\class{RegexObject} or \class{MatchObject}, but that shouldn't be much - %of a problem since no one should have been doing that in the first - %place. - - % ====================================================================== - \section{Core Changes} - Various minor changes have been made to Python's syntax and built-in functions. None of the changes are very far-reaching, but they're handy conveniences. ! A change to syntax makes it more convenient to call a given function with a tuple of arguments and/or a dictionary of keyword arguments. ! In Python 1.5 and earlier, you do this with the \function{apply()} built-in function: \code{apply(f, \var{args}, \var{kw})} calls the function \function{f()} with the argument tuple \var{args} and the ! keyword arguments in the dictionary \var{kw}. Thanks to a patch from ! Greg Ewing, 2.0 adds \code{f(*\var{args}, **\var{kw})} as a shorter and clearer way to achieve the same effect. This syntax is symmetrical with the syntax for defining functions: --- 418,438 ---- cycle collection for Python'' and ``Finalization again''. % ====================================================================== ! \section{Other Core Changes} Various minor changes have been made to Python's syntax and built-in functions. None of the changes are very far-reaching, but they're handy conveniences. ! \subsection{Minor Language Changes} ! ! A new syntax makes it more convenient to call a given function with a tuple of arguments and/or a dictionary of keyword arguments. ! In Python 1.5 and earlier, you'd use the \function{apply()} built-in function: \code{apply(f, \var{args}, \var{kw})} calls the function \function{f()} with the argument tuple \var{args} and the ! keyword arguments in the dictionary \var{kw}. \function{apply()} ! is the same in 2.0, but thanks to a patch from ! Greg Ewing, \code{f(*\var{args}, **\var{kw})} as a shorter and clearer way to achieve the same effect. This syntax is symmetrical with the syntax for defining functions: *************** *** 586,591 **** ... \end{verbatim} ! A new format style is available when using the \code{\%} operator. '\%r' will insert the \function{repr()} of its argument. This was also added from symmetry considerations, this time for symmetry with --- 444,467 ---- ... \end{verbatim} + + The \keyword{print} statement can now have its output directed to a + file-like object by following the \keyword{print} with \code{>> + \var{fileobj}}, similar to the redirection operator in Unix shells. + Previously you'd either have to use the \method{write()} method of the + file-like object, which lacks the convenience and simplicity of + \keyword{print}, or you could assign a new value to \code{sys.stdout} + and then restore the old value. For sending output to standard error, + it's much easier to write this: + + \begin{verbatim} + print >> sys.stderr, "Warning: action field not supplied" + \end{verbatim} + + Modules can now be renamed on importing them, using the syntax + \code{import \var{module} as \var{name}} or \code{from \var{module} + import \var{name} as \var{othername}}. The patch was submitted by + Thomas Wouters. ! A new format style is available when using the \code{\%} operator; '\%r' will insert the \function{repr()} of its argument. This was also added from symmetry considerations, this time for symmetry with *************** *** 594,615 **** string containing \verb|'abc' abc|. - A new built-in, \function{zip(\var{seq1}, \var{seq2}, ...)}, has been - added. \function{zip()} returns a list of tuples where each tuple - contains the i-th element from each of the argument sequences. The - difference between \function{zip()} and \code{map(None, \var{seq1}, - \var{seq2})} is that \function{map()} raises an error if the sequences - aren't all of the same length, while \function{zip()} truncates the - returned list to the length of the shortest argument sequence. - - The \function{int()} and \function{long()} functions now accept an - optional ``base'' parameter when the first argument is a string. - \code{int('123', 10)} returns 123, while \code{int('123', 16)} returns - 291. \code{int(123, 16)} raises a \exception{TypeError} exception - with the message ``can't convert non-string with explicit base''. - - Modules can now be renamed on importing them, using the syntax - \code{import \var{module} as \var{name}} or \code{from \var{module} - import \var{name} as \var{othername}}. - Previously there was no way to implement a class that overrode Python's built-in \keyword{in} operator and implemented a custom --- 470,473 ---- *************** *** 639,653 **** The comparison \code{a==b} returns true, because the two recursive ! data structures are isomorphic. ! \footnote{See the thread ``trashcan and PR\#7'' in the April 2000 archives of the python-dev mailing list for the discussion leading up to this implementation, and some useful relevant links. %http://www.python.org/pipermail/python-dev/2000-April/004834.html } Work has been done on porting Python to 64-bit Windows on the Itanium ! processor, mostly by Trent Mick of ActiveState. (Confusingly, \code{sys.platform} is still \code{'win32'} on ! Win64 because it seems that for ease of porting, MS Visual C++ treats code ! as 32 bit. ! ) PythonWin also supports Windows CE; see the Python CE page at ! \url{http://starship.python.net/crew/mhammond/ce/} for more information. An attempt has been made to alleviate one of Python's warts, the --- 497,514 ---- The comparison \code{a==b} returns true, because the two recursive ! data structures are isomorphic. \footnote{See the thread ``trashcan ! and PR\#7'' in the April 2000 archives of the python-dev mailing list ! for the discussion leading up to this implementation, and some useful ! relevant links. %http://www.python.org/pipermail/python-dev/2000-April/004834.html } Work has been done on porting Python to 64-bit Windows on the Itanium ! processor, mostly by Trent Mick of ActiveState. (Confusingly, ! \code{sys.platform} is still \code{'win32'} on Win64 because it seems ! that for ease of porting, MS Visual C++ treats code as 32 bit on Itanium.) ! PythonWin also supports Windows CE; see the Python CE page at ! \url{http://starship.python.net/crew/mhammond/ce/} for more ! information. An attempt has been made to alleviate one of Python's warts, the *************** *** 669,672 **** --- 530,549 ---- \end{verbatim} + \subsection{Changes to Built-in Functions} + + A new built-in, \function{zip(\var{seq1}, \var{seq2}, ...)}, has been + added. \function{zip()} returns a list of tuples where each tuple + contains the i-th element from each of the argument sequences. The + difference between \function{zip()} and \code{map(None, \var{seq1}, + \var{seq2})} is that \function{map()} raises an error if the sequences + aren't all of the same length, while \function{zip()} truncates the + returned list to the length of the shortest argument sequence. + + The \function{int()} and \function{long()} functions now accept an + optional ``base'' parameter when the first argument is a string. + \code{int('123', 10)} returns 123, while \code{int('123', 16)} returns + 291. \code{int(123, 16)} raises a \exception{TypeError} exception + with the message ``can't convert non-string with explicit base''. + A new variable holding more detailed version information has been added to the \module{sys} module. \code{sys.version_info} is a tuple *************** *** 693,696 **** --- 570,663 ---- can be reduced to a single \code{return dict.setdefault(key, [])} statement. + + % ====================================================================== + \section{Porting to 2.0} + + New Python releases try hard to be compatible with previous releases, + and the record has been pretty good. However, some changes are + considered useful enough, often fixing initial design decisions that + turned to be actively mistaken, that breaking backward compatibility + can't always be avoided. This section lists the changes in Python 2.0 + that may cause old Python code to break. + + The change which will probably break the most code is tightening up + the arguments accepted by some methods. Some methods would take + multiple arguments and treat them as a tuple, particularly various + list methods such as \method{.append()} and \method{.insert()}. + In earlier versions of Python, if \code{L} is a list, \code{L.append( + 1,2 )} appends the tuple \code{(1,2)} to the list. In Python 2.0 this + causes a \exception{TypeError} exception to be raised, with the + message: 'append requires exactly 1 argument; 2 given'. The fix is to + simply add an extra set of parentheses to pass both values as a tuple: + \code{L.append( (1,2) )}. + + The earlier versions of these methods were more forgiving because they + used an old function in Python's C interface to parse their arguments; + 2.0 modernizes them to use \function{PyArg_ParseTuple}, the current + argument parsing function, which provides more helpful error messages + and treats multi-argument calls as errors. If you absolutely must use + 2.0 but can't fix your code, you can edit \file{Objects/listobject.c} + and define the preprocessor symbol \code{NO_STRICT_LIST_APPEND} to + preserve the old behaviour; this isn't recommended. + + Some of the functions in the \module{socket} module are still + forgiving in this way. For example, \function{socket.connect( + ('hostname', 25) )} is the correct form, passing a tuple representing + an IP address, but \function{socket.connect( 'hostname', 25 )} also + works. \function{socket.connect_ex()} and \function{socket.bind()} are + similarly easy-going. 2.0alpha1 tightened these functions up, but + because the documentation actually used the erroneous multiple + argument form, many people wrote code which would break with the + stricter checking. GvR backed out the changes in the face of public + reaction, so for the\module{socket} module, the documentation was + fixed and the multiple argument form is simply marked as deprecated; + it \emph{will} be tightened up again in a future Python version. + + Some work has been done to make integers and long integers a bit more + interchangeable. In 1.5.2, large-file support was added for Solaris, + to allow reading files larger than 2Gb; this made the \method{tell()} + method of file objects return a long integer instead of a regular + integer. Some code would subtract two file offsets and attempt to use + the result to multiply a sequence or slice a string, but this raised a + \exception{TypeError}. In 2.0, long integers can be used to multiply + or slice a sequence, and it'll behave as you'd intuitively expect it + to; \code{3L * 'abc'} produces 'abcabcabc', and \code{ + (0,1,2,3)[2L:4L]} produces (2,3). Long integers can also be used in + various new places where previously only integers were accepted, such + as in the \method{seek()} method of file objects. + + The subtlest long integer change of all is that the \function{str()} + of a long integer no longer has a trailing 'L' character, though + \function{repr()} still includes it. The 'L' annoyed many people who + wanted to print long integers that looked just like regular integers, + since they had to go out of their way to chop off the character. This + is no longer a problem in 2.0, but code which assumes the 'L' is + there, and does \code{str(longval)[:-1]} will now lose the final + digit. + + Taking the \function{repr()} of a float now uses a different + formatting precision than \function{str()}. \function{repr()} uses + \code{\%.17g} format string for C's \function{sprintf()}, while + \function{str()} uses \code{\%.12g} as before. The effect is that + \function{repr()} may occasionally show more decimal places than + \function{str()}, for numbers + For example, the number 8.1 can't be represented exactly in binary, so + \code{repr(8.1)} is \code{'8.0999999999999996'}, while str(8.1) is + \code{'8.1'}. + + The \code{-X} command-line option, which turned all standard + exceptions into strings instead of classes, has been removed; the + standard exceptions will now always be classes. The + \module{exceptions} module containing the standard exceptions was + translated from Python to a built-in C module, written by Barry Warsaw + and Fredrik Lundh. + + % Commented out for now -- I don't think anyone will care. + %The pattern and match objects provided by SRE are C types, not Python + %class instances as in 1.5. This means you can no longer inherit from + %\class{RegexObject} or \class{MatchObject}, but that shouldn't be much + %of a problem since no one should have been doing that in the first + %place. + % ====================================================================== \section{Extending/Embedding Changes} *************** *** 754,757 **** --- 721,807 ---- requires an ANSI C compiler, and can no longer be done using a compiler that only supports K\&R C. + + % ====================================================================== + \section{Distutils: Making Modules Easy to Install} + + Before Python 2.0, installing modules was a tedious affair -- there + was no way to figure out automatically where Python is installed, or + what compiler options to use for extension modules. Software authors + had to go through an ardous ritual of editing Makefiles and + configuration files, which only really work on Unix and leave Windows + and MacOS unsupported. Software users faced wildly differing + installation instructions + + The SIG for distribution utilities, shepherded by Greg Ward, has + created the Distutils, a system to make package installation much + easier. They form the \module{distutils} package, a new part of + Python's standard library. In the best case, installing a Python + module from source will require the same steps: first you simply mean + unpack the tarball or zip archive, and the run ``\code{python setup.py + install}''. The platform will be automatically detected, the compiler + will be recognized, C extension modules will be compiled, and the + distribution installed into the proper directory. Optional + command-line arguments provide more control over the installation + process, the distutils package offers many places to override defaults + -- separating the build from the install, building or installing in + non-default directories, and more. + + In order to use the Distutils, you need to write a \file{setup.py} + script. For the simple case, when the software contains only .py + files, a minimal \file{setup.py} can be just a few lines long: + + \begin{verbatim} + from distutils.core import setup + setup (name = "foo", version = "1.0", + py_modules = ["module1", "module2"]) + \end{verbatim} + + The \file{setup.py} file isn't much more complicated if the software + consists of a few packages: + + \begin{verbatim} + from distutils.core import setup + setup (name = "foo", version = "1.0", + packages = ["package", "package.subpackage"]) + \end{verbatim} + + A C extension can be the most complicated case; here's an example taken from + the PyXML package: + + + \begin{verbatim} + from distutils.core import setup, Extension + + expat_extension = Extension('xml.parsers.pyexpat', + define_macros = [('XML_NS', None)], + include_dirs = [ 'extensions/expat/xmltok', + 'extensions/expat/xmlparse' ], + sources = [ 'extensions/pyexpat.c', + 'extensions/expat/xmltok/xmltok.c', + 'extensions/expat/xmltok/xmlrole.c', + ] + ) + setup (name = "PyXML", version = "0.5.4", + ext_modules =[ expat_extension ] ) + + \end{verbatim} + + The Distutils can also take care of creating source and binary + distributions. The ``sdist'' command, run by ``\code{python setup.py + sdist}', builds a source distribution such as \file{foo-1.0.tar.gz}. + Adding new commands isn't difficult, ``bdist_rpm'' and + ``bdist_wininst'' commands have already been contributed to create an + RPM distribution and a Windows installer for the software, + respectively. Commands to create other distribution formats such as + Debian packages and Solaris \file{.pkg} files are in various stages of + development. + + All this is documented in a new manual, \textit{Distributing Python + Modules}, that joins the basic set of Python documentation. + + % ====================================================================== + %\section{New XML Code} + + %XXX write this section... % ====================================================================== |
|
From: A.M. K. <aku...@us...> - 2000-08-17 23:37:04
|
Update of /cvsroot/py-howto/pyhowto In directory slayer.i.sourceforge.net:/tmp/cvs-serv6146 Modified Files: python-2.0.tex Log Message: Mention the new 'import X as Y' syntax Index: python-2.0.tex =================================================================== RCS file: /cvsroot/py-howto/pyhowto/python-2.0.tex,v retrieving revision 1.23 retrieving revision 1.24 diff -C2 -r1.23 -r1.24 *** python-2.0.tex 2000/08/17 00:27:06 1.23 --- python-2.0.tex 2000/08/17 23:37:01 1.24 *************** *** 608,611 **** --- 608,615 ---- with the message ``can't convert non-string with explicit base''. + Modules can now be renamed on importing them, using the syntax + \code{import \var{module} as \var{name}} or \code{from \var{module} + import \var{name} as \var{othername}}. + Previously there was no way to implement a class that overrode Python's built-in \keyword{in} operator and implemented a custom |
|
From: Fred L. D. <fd...@us...> - 2000-08-17 20:39:07
|
Update of /cvsroot/py-howto/pyhowto In directory slayer.i.sourceforge.net:/tmp/cvs-serv6312 Modified Files: xml-ref.tex Log Message: Minor markup nits. AttributeList: Note that the values() and items() methods are supported as well. Index: xml-ref.tex =================================================================== RCS file: /cvsroot/py-howto/pyhowto/xml-ref.tex,v retrieving revision 1.6 retrieving revision 1.7 diff -C2 -r1.6 -r1.7 *** xml-ref.tex 1999/12/09 12:58:18 1.6 --- xml-ref.tex 2000/08/17 20:39:04 1.7 *************** *** 136,140 **** non-validating XML parser. If \var{parser} is specified, it must be a parser name; otherwise, a list of available parsers is checked and the ! fastest one chosen. \end{funcdesc} --- 136,140 ---- non-validating XML parser. If \var{parser} is specified, it must be a parser name; otherwise, a list of available parsers is checked and the ! fastest available is chosen. \end{funcdesc} *************** *** 203,207 **** \begin{methoddesc}{reset}{} ! Makes the parser start parsing afresh. \end{methoddesc} --- 203,208 ---- \begin{methoddesc}{reset}{} ! Makes the parser start parsing afresh, discarding any buffered input ! data. \end{methoddesc} *************** *** 219,224 **** Returns a SAX driver for the first available parser of the parsers in the list. Note that the list contains drivers, so it first tries ! the driver and if that exists imports it to see if the parser also ! exists. If no parsers are available a \class{SAXException} is thrown. Optionally, \var{driver_name} can be a string containing the name of --- 220,226 ---- Returns a SAX driver for the first available parser of the parsers in the list. Note that the list contains drivers, so it first tries ! the driver and, if that exists, imports it to determine if the parser ! also exists. If no parsers are available a \exception{SAXException} is ! thrown. Optionally, \var{driver_name} can be a string containing the name of *************** *** 239,243 **** specified or defaulted attributes will be reported). Note that the information returned by this object will be valid only during the ! scope of the \method{DocumentHandler.startElement} callback, and the attributes will not necessarily be provided in the order declared or specified. --- 241,245 ---- specified or defaulted attributes will be reported). Note that the information returned by this object will be valid only during the ! scope of the \method{DocumentHandler.startElement()} callback, and the attributes will not necessarily be provided in the order declared or specified. *************** *** 278,283 **** all warnings and errors. There are three levels of errors available: warnings, (possibly) recoverable errors, and ! unrecoverable errors. All methods take a SAXParseException as the ! only parameter. \end{classdesc} --- 280,285 ---- all warnings and errors. There are three levels of errors available: warnings, (possibly) recoverable errors, and ! unrecoverable errors. All methods take a ! \exception{SAXParseException} as the only parameter. \end{classdesc} *************** *** 339,343 **** The \class{AttributeList} class supports some of the behaviour of Python dictionaries; the \method{len()}, \method{has_key()}, ! \method{keys()} methods are available, and \code{attr['href']} will retrieve the value of the \attribute{href} attribute. There are also additional methods specific to \class{AttributeList}: --- 341,346 ---- The \class{AttributeList} class supports some of the behaviour of Python dictionaries; the \method{len()}, \method{has_key()}, ! \method{items()}, \method{keys()} and \method{values()} methods are ! available, and \code{attr['href']} will retrieve the value of the \attribute{href} attribute. There are also additional methods specific to \class{AttributeList}: |
|
From: A.M. K. <aku...@us...> - 2000-08-17 00:39:25
|
Update of /cvsroot/py-howto/pyhowto In directory slayer.i.sourceforge.net:/tmp/cvs-serv16454 Modified Files: curses.tex Log Message: Fixed broken link to ncurses FAQ, and removed link to Oliver's page Remove placeholder for reference docs, since they're now in the LibRef Index: curses.tex =================================================================== RCS file: /cvsroot/py-howto/pyhowto/curses.tex,v retrieving revision 1.7 retrieving revision 1.8 diff -C2 -r1.7 -r1.8 *** curses.tex 2000/08/15 19:01:25 1.7 --- curses.tex 2000/08/17 00:39:22 1.8 *************** *** 467,471 **** as another demo. We can always use more of them! ! The ncurses FAQ: \url{http://www.clark.net/pub/dickey/ncurses/ncurses.faq.html} Any other suggested references? --- 467,471 ---- as another demo. We can always use more of them! ! The ncurses FAQ: \url{http://dickey.his.com/ncurses/ncurses.faq.html} Any other suggested references? |
|
From: A.M. K. <aku...@us...> - 2000-08-17 00:27:09
|
Update of /cvsroot/py-howto/pyhowto In directory slayer.i.sourceforge.net:/tmp/cvs-serv4139 Modified Files: python-2.0.tex Log Message: Add section on list comprehension Comment out the unwritten XML section mymalloc.h -> pymem.h Index: python-2.0.tex =================================================================== RCS file: /cvsroot/py-howto/pyhowto/python-2.0.tex,v retrieving revision 1.22 retrieving revision 1.23 diff -C2 -r1.22 -r1.23 *** python-2.0.tex 2000/08/16 02:52:37 1.22 --- python-2.0.tex 2000/08/17 00:27:06 1.23 *************** *** 112,116 **** returns a 2-tuple \code{(\var{string}, \var{length})}. \var{string} is an 8-bit string containing a portion (perhaps all) of the Unicode ! string converted into the given encoding, and \var{length} tells you how much of the Unicode string was converted. \item \var{decode_func} is the mirror of \var{encode_func}, --- 112,117 ---- returns a 2-tuple \code{(\var{string}, \var{length})}. \var{string} is an 8-bit string containing a portion (perhaps all) of the Unicode ! string converted into the given encoding, and \var{length} tells you ! how much of the Unicode string was converted. \item \var{decode_func} is the mirror of \var{encode_func}, *************** *** 167,170 **** --- 168,286 ---- % ====================================================================== + \section{List Comprehensions} + + Lists are a workhorse data type in Python, and many programs + manipulate a list at some point. Two common operations on lists are + to loop over them, and either pick out the elements that meet a + certain criterion, or apply some function to each element. For + example, given a list of strings, you might want to pull out all the + strings containing a given substring, or strip off trailing whitespace + from each line. + + The existing \function{map()} and \function{filter()} functions can be + used for this purpose, but they require a function as one of their + arguments. This is fine if there's an existing built-in function that + can be passed directly, but if there isn't, you have to create a + little function to do the required work, and Python's scoping rules + make the result ugly if the little function needs additional + information. Take the first example in the previous paragraph, + finding all the strings in the list containing a given substring. You + could write the following to do it: + + \begin{verbatim} + # Given the list L, make a list of all strings + # containing the substring S. + sublist = filter( lambda s, substring=S: + string.find(s, substring) != -1, + L) + \end{verbatim} + + Because of Python's scoping rules, a default argument is used so that + the anonymous function created by the \keyword{lambda} statement knows + what substring is being searched for. List comprehensions make this + cleaner: + + \begin{verbatim} + sublist = [ s for s in L if string.find(s, S) != -1 ] + \end{verbatim} + + List comprehensions have the form: + + \begin{verbatim} + [ expression for expr in sequence1 + for expr2 in sequence2 ... + for exprN in sequenceN + if condition + \end{verbatim} + + The \keyword{for}...\keyword{in} clauses contain the sequences to be + iterated over. The sequences do not have to be the same length, + because they are \emph{not} iterated over in parallel, but + from left to right; this is explained more clearly in the following + paragraphs. The elements of the generated list will be the successive + values of \var{expression}. The final \keyword{if} clause is + optional; if present, \var{expression} is only evaluated and added to + the result if \var{condition} is true. + + To make the semantics very clear, a list comprehension is equivalent + to the following Python code: + + \begin{verbatim} + for expr1 in sequence1: + for expr2 in sequence2: + ... + for exprN in sequenceN: + if (condition): + # Append the value of + # the expression to the + # resulting list. + \end{verbatim} + + This means that when there are \keyword{for}...\keyword{in} clauses, + the resulting list will be equal to the product of the lengths of all + the sequences. If you have two lists of length 3, the output list is + 9 elements long: + + \begin{verbatim} + seq1 = 'abc' + seq2 = (1,2,3) + >>> [ (x,y) for x in seq1 for y in seq2] + [('a', 1), ('a', 2), ('a', 3), ('b', 1), ('b', 2), ('b', 3), ('c', 1), + ('c', 2), ('c', 3)] + \end{verbatim} + + To avoid introducing an ambiguity into Python's grammar, if + \var{expression} is creating a tuple, it must be surrounded with + parentheses. The first list comprehension below is a syntax error, + while the second one is correct: + + \begin{verbatim} + # Syntax error + [ x,y for x in seq1 for y in seq2] + # Correct + [ (x,y) for x in seq1 for y in seq2] + \end{verbatim} + + + The idea of list comprehensions originally comes from the functional + programming language Haskell (\url{http://www.haskell.org}). Greg + Ewing argued most effectively for adding them to Python and wrote the + initial list comprehension patch, which was then discussed for a + seemingly endless time on the python-dev mailing list and kept + up-to-date by Skip Montanaro. + + + + + A list comprehension has the form [ e | q[1], ..., q[n] ], n>=1, where + the q[i] qualifiers are either + * generators of the form p <- e, where p is a pattern (see Section + 3.17) of type t and e is an expression of type [t] + * guards, which are arbitrary expressions of type Bool + * local bindings that provide new definitions for use in the + generated expression e or subsequent guards and generators. + + + % ====================================================================== \section{Distutils: Making Modules Easy to Install} *************** *** 354,360 **** % ====================================================================== ! \section{New XML Code} ! XXX write this section... % ====================================================================== --- 470,476 ---- % ====================================================================== ! %\section{New XML Code} ! %XXX write this section... % ====================================================================== *************** *** 613,617 **** to make it easy to have the Python interpreter use a custom allocator instead of C's standard \function{malloc()}. For documentation, read ! the comments in \file{Include/mymalloc.h} and \file{Include/objimpl.h}. For the lengthy discussions during which the interface was hammered out, see the Web archives of the 'patches' --- 729,733 ---- to make it easy to have the Python interpreter use a custom allocator instead of C's standard \function{malloc()}. For documentation, read ! the comments in \file{Include/pymem.h} and \file{Include/objimpl.h}. For the lengthy discussions during which the interface was hammered out, see the Web archives of the 'patches' |
|
From: Fred L. D. <fd...@us...> - 2000-08-16 03:39:55
|
Update of /cvsroot/py-howto/pyhowto In directory slayer.i.sourceforge.net:/tmp/cvs-serv28991 Modified Files: Makefile Log Message: Factored out the mkhowto command into a variable. Added python-2.0.tex to the list of HOWTO documents. Index: Makefile =================================================================== RCS file: /cvsroot/py-howto/pyhowto/Makefile,v retrieving revision 1.2 retrieving revision 1.3 diff -C2 -r1.2 -r1.3 *** Makefile 1999/10/05 00:40:35 1.2 --- Makefile 2000/08/16 03:39:51 1.3 *************** *** 3,8 **** regex-to-re.tex regex.tex rexec.tex \ sockets.tex sorting.tex \ ! xml-howto.tex xml-ref.tex all: DVI PDF PS HTML --- 3,12 ---- regex-to-re.tex regex.tex rexec.tex \ sockets.tex sorting.tex \ ! xml-howto.tex xml-ref.tex \ ! python-2.0.tex + MKHOWTO=../tools/mkhowto + + all: DVI PDF PS HTML *************** *** 17,21 **** DVI: for i in $(HOWTOS) ; do \ ! ../tools/mkhowto --dvi $$i ;\ base=`basename $$i .tex` ;\ mv $$base.dvi dvi/ ;\ --- 21,25 ---- DVI: for i in $(HOWTOS) ; do \ ! $(MKHOWTO) --dvi $$i ;\ base=`basename $$i .tex` ;\ mv $$base.dvi dvi/ ;\ *************** *** 24,28 **** HTML: for i in $(HOWTOS) ; do \ ! ../tools/mkhowto.sh --html --split 1 $$i ;\ base=`basename $$i .tex` ;\ rm -rf $$base/TMP/ ;\ --- 28,32 ---- HTML: for i in $(HOWTOS) ; do \ ! $(MKHOWTO) --html --split 1 $$i ;\ base=`basename $$i .tex` ;\ rm -rf $$base/TMP/ ;\ *************** *** 31,35 **** PDF: for i in $(HOWTOS) ; do \ ! ../tools/mkhowto.sh --pdf $$i ;\ base=`basename $$i .tex` ;\ mv $$base.pdf pdf/ ;\ --- 35,39 ---- PDF: for i in $(HOWTOS) ; do \ ! $(MKHOWTO) --pdf $$i ;\ base=`basename $$i .tex` ;\ mv $$base.pdf pdf/ ;\ *************** *** 38,42 **** PS: for i in $(HOWTOS) ; do \ ! ../tools/mkhowto.sh --ps $$i ;\ base=`basename $$i .tex` ;\ mv $$base.ps ps/ ;\ --- 42,46 ---- PS: for i in $(HOWTOS) ; do \ ! $(MKHOWTO) --ps $$i ;\ base=`basename $$i .tex` ;\ mv $$base.ps ps/ ;\ |
|
From: A.M. K. <aku...@us...> - 2000-08-16 02:52:41
|
Update of /cvsroot/py-howto/pyhowto In directory slayer.i.sourceforge.net:/tmp/cvs-serv17585 Modified Files: python-2.0.tex Log Message: Mention setdefault() method for dicts Index: python-2.0.tex =================================================================== RCS file: /cvsroot/py-howto/pyhowto/python-2.0.tex,v retrieving revision 1.21 retrieving revision 1.22 diff -C2 -r1.21 -r1.22 *** python-2.0.tex 2000/08/04 12:40:35 1.21 --- python-2.0.tex 2000/08/16 02:52:37 1.22 *************** *** 557,560 **** --- 557,576 ---- \code{""} for a final release. + Dictionaries have an odd new method, \method{setdefault(\var{key}, + \var{default})}, which behaves similarly to the existing + \method{get()} method. However, if the key is missing, + \method{setdefault()} both returns the value of \var{default} as + \method{get()} would do, and also inserts it into the dictionary as + the value for \var{key}. Thus, the following lines of code: + + \begin{verbatim} + if dict.has_key( key ): return dict[key] + else: + dict[key] = [] + return dict[key] + \end{verbatim} + + can be reduced to a single \code{return dict.setdefault(key, [])} statement. + % ====================================================================== \section{Extending/Embedding Changes} |
|
From: Fred L. D. <fd...@us...> - 2000-08-15 19:01:29
|
Update of /cvsroot/py-howto/pyhowto In directory slayer.i.sourceforge.net:/tmp/cvs-serv2944 Modified Files: curses.tex Log Message: Typo: curses.wrapper\wrapper() --> curses.wrapper.wrapper() This prevented formatting. Index: curses.tex =================================================================== RCS file: /cvsroot/py-howto/pyhowto/curses.tex,v retrieving revision 1.6 retrieving revision 1.7 diff -C2 -r1.6 -r1.7 *** curses.tex 2000/08/11 14:55:39 1.6 --- curses.tex 2000/08/15 19:01:25 1.7 *************** *** 320,324 **** To use colour, you must call the \function{start_color()} function soon after calling \function{initscr()}, to initialize the default ! colour set (the \function{curses.wrapper\wrapper()} function does this automatically). Once that's done, the \function{has_colors()} function returns TRUE if the terminal in use can actually display --- 320,324 ---- To use colour, you must call the \function{start_color()} function soon after calling \function{initscr()}, to initialize the default ! colour set (the \function{curses.wrapper.wrapper()} function does this automatically). Once that's done, the \function{has_colors()} function returns TRUE if the terminal in use can actually display |
|
From: A.M. K. <aku...@us...> - 2000-08-11 14:55:43
|
Update of /cvsroot/py-howto/pyhowto In directory slayer.i.sourceforge.net:/tmp/cvs-serv8960 Modified Files: curses.tex Log Message: ESR's extensively reworked version Index: curses.tex =================================================================== RCS file: /cvsroot/py-howto/pyhowto/curses.tex,v retrieving revision 1.5 retrieving revision 1.6 diff -C2 -r1.5 -r1.6 *** curses.tex 2000/08/09 18:02:45 1.5 --- curses.tex 2000/08/11 14:55:39 1.6 *************** *** 3,11 **** \title{Curses Programming with Python} ! \release{1.0} - \author{A.M. Kuchling} \authoraddress{\email{am...@bi...}} \begin{document} --- 3,12 ---- \title{Curses Programming with Python} ! \release{2.0} \author{A.M. Kuchling} \authoraddress{\email{am...@bi...}} + \author{Eric S. Raymond} + \authoraddress{\email{es...@th...}} \begin{document} *************** *** 16,24 **** This document describes how to write text-mode programs with Python, using the curses extension module to control the display. - - This document is available in several formats, including PostScript, - PDF, HTML and plain ASCII, from the Python HOWTO page at - \url{http://www.python.org/doc/howto/}. - \end{abstract} --- 17,20 ---- *************** *** 27,31 **** \section{What is curses?} ! curses is a display library for text-based terminals; such terminals include VT100s, the Linux console, and the simulated terminal provided by X11 programs such as xterm and rxvt. Display terminals support --- 23,28 ---- \section{What is curses?} ! The curses library supplies a terminal-independent screen-painting and ! keyboard-handling facility for text-based terminals; such terminals include VT100s, the Linux console, and the simulated terminal provided by X11 programs such as xterm and rxvt. Display terminals support *************** *** 34,68 **** use widely differing codes, and often have their own minor quirks. ! curses hides all the details of different terminals, and provides the ! programmer with an abstraction of a display, containing multiple ! non-overlapping windows. The contents of a window can be changed in ! various ways--adding text, erasing it, changing its appearance--and ! the curses library will automagically figure out what control codes ! need to be sent to the terminal to produce the right output. ! curses was originally written for BSD Unix; the later System V versions of Unix from AT\&T added many enhancements and new functions. BSD curses is no longer maintained, having been replaced by ncurses, ! which is a GPLed implementation of the AT\&T interface. If you're ! using a freeware Unix such as Linux or FreeBSD, your system almost certainly uses ncurses. Since most current commercial Unix versions are based on System V code, all the functions described here will ! probably be available. Older systems may not support everything, ! though. \subsection{The Python curses module} ! The original Python curses module was written by Lance Ellinghouse, ! and is included with the Python source distribution, version 1.5 or ! earlier. It supports all the basic operations of displaying text, but ! doesn't support System V features such as colour. Later, Oliver ! Andrich enhanced this module by adding support for many of the missing ! features. ! ! Both modules are a fairly simple wrapper over the C functions provided ! by curses; if you're already familiar with curses programming in C, ! it's really easy to transfer that knowledge to Python. The biggest ! difference is that the Python interface makes things simpler, by ! merging different C functions such as \function{addstr}, \function{mvaddstr}, \function{mvwaddstr}, into a single \method{addstr()} method. You'll see this covered in more detail --- 31,59 ---- use widely differing codes, and often have their own minor quirks. ! The curses library hides all the details of different terminals, and ! provides the programmer with an abstraction of a display, containing ! multiple non-overlapping windows. The contents of a window can be ! changed in various ways--adding text, erasing it, changing its ! appearance--and the curses library will automagically figure out what ! control codes need to be sent to the terminal to produce the right ! output. ! The curses library was originally written for BSD Unix; the later System V versions of Unix from AT\&T added many enhancements and new functions. BSD curses is no longer maintained, having been replaced by ncurses, ! which is an open-source implementation of the AT\&T interface. If you're ! using an open-source Unix such as Linux or FreeBSD, your system almost certainly uses ncurses. Since most current commercial Unix versions are based on System V code, all the functions described here will ! probably be available. The older versions of curses carried by some ! proprietary Unixes may not support everything, though. \subsection{The Python curses module} ! Thy Python module is a fairly simple wrapper over the C functions ! provided by curses; if you're already familiar with curses programming ! in C, it's really easy to transfer that knowledge to Python. The ! biggest difference is that the Python interface makes things simpler, ! by merging different C functions such as \function{addstr}, \function{mvaddstr}, \function{mvwaddstr}, into a single \method{addstr()} method. You'll see this covered in more detail *************** *** 70,98 **** This HOWTO is simply an introduction to writing text-mode programs ! with curses and Python, and doesn't even attempt to be a complete ! guide to the curses API. It will, however, give you the basic ideas. ! This documentation doesn't even cover every single curses function ! available in the Python modules; that would make this a very long ! HOWTO, and would duplicate much of the information in the curses ! documentation. You should consult the documentation for your curses ! implementation to learn about its quirks. ! ! To install the regular curses extension, you only have to uncomment ! the corresponding line of Modules/Setup in your Python source tree, ! and recompile. You may have to tweak the required libraries, as ! described in the comment: ! ! \begin{verbatim} ! # Lance's curses module. This requires the System V version of ! # curses, sometimes known as ncurses (e.g. on Linux, link with ! # -lncurses instead of -lcurses; on SunOS 4.1.3, insert ! # -I/usr/5include -L/usr/5lib before -lcurses). ! ! curses cursesmodule.c -lcurses -ltermcap ! \end{verbatim} ! ! To install the newer module, fetch the most recent version from ! \url{http://andrich.net/python/selfmade.html\#ncursesmodule}, unpack ! it, and simply run \code{make}. \section{Starting and ending a curses Application} --- 61,68 ---- This HOWTO is simply an introduction to writing text-mode programs ! with curses and Python. It doesn't attempt to be a complete guide to ! the curses API; for that, see the Python library guide's serction on ! ncurses, and the C manual pages for ncurses. It will, however, give ! you the basic ideas. \section{Starting and ending a curses Application} *************** *** 140,148 **** \end{verbatim} ! Terminating a curses application is much easier than starting one. ! Simply call the \function{endwin()} function to restore the terminal ! to its original operating mode. \begin{verbatim} curses.endwin() \end{verbatim} --- 110,125 ---- \end{verbatim} ! Terminating a curses application is much easier than starting one. ! You'll need to call \begin{verbatim} + curses.nobreak(); curses.keypad(0); curses.echo() + \end{verbatim} + + to reverse the curses-friendly terminal settings. Then call the + \function{endwin()} function to restore the terminal to its original + operating mode. + + \begin{verbatim} curses.endwin() \end{verbatim} *************** *** 155,195 **** makes using the shell difficult. ! In Python you can avoid this and make debugging much easier by copying ! the following top-level code. It initializes the terminal and then ! calls the \function{main()} function, which will be your application's ! code. If \function{main()} raises an uncaught exception, the terminal ! is restored to its normal state before printing the traceback. ! ! \begin{verbatim} ! def main(stdscr): ! # Your code goes here ! ... ! ! if __name__=='__main__': ! import curses, traceback ! try: ! # Initialize curses ! stdscr=curses.initscr() ! # Turn off echoing of keys, and enter cbreak mode, ! # where no buffering is performed on keyboard input ! curses.noecho() ; curses.cbreak() ! ! # In keypad mode, escape sequences for special keys ! # (like the cursor keys) will be interpreted and ! # a special value like curses.KEY_LEFT will be returned ! stdscr.keypad(1) ! main(stdscr) # Enter the main loop ! # Set everything back to normal ! stdscr.keypad(0) ! curses.echo() ; curses.nocbreak() ! curses.endwin() # Terminate curses ! except: ! # In the event of an error, restore the terminal ! # to a sane state. ! stdscr.keypad(0) ! curses.echo() ; curses.nocbreak() ! curses.endwin() ! traceback.print_exc() # Print the exception ! \end{verbatim} \section{Windows and Pads} --- 132,144 ---- makes using the shell difficult. ! In Python you can avoid these complications and make debugging much ! easier by importing the module \module{curses.wrapper}. It supplies a ! function \function{wrapper} that takes a hook argument. It does the ! initializations described above, and also initializes colors if color ! support is present. It then runs your hook, and then finally ! deinitializes appropriately. The hook is called inside a try-catch ! hook which catches exceptions, performs curses deinitialization, and ! then passes the exception upwards. Thus, your terminal won't be left ! in a funny state on exception. \section{Windows and Pads} *************** *** 265,268 **** --- 214,226 ---- ordinary windows and support the same methods. + If you have multiple windows and pads on screen there is a more + efficient way to go, which will prevent annoying screen flicker at + refresh time. Use the methods \method{noutrefresh()} and/or + \method{noutrefresh()} of each window to update the data structure + representing the desired state of the screen; then change the physical + screen to match the desired state in one go with the function + \function{doupdate()}. The normal \method{refresh()} method calls + \function{doupdate()} as its last act. + \section{Displaying Text} *************** *** 314,324 **** ensure that the cursor is positioned in some location where it won't be distracting; it can be confusing to have the cursor blinking at ! some apparently random location. If your application doesn't need a ! blinking cursor at all, you can call the ! \function{leaveok(\var{bool})} method. When \var{bool} is true, the curses library will attempt to suppress the flashing cursor, and you won't need to worry about leaving it in odd locations. - \subsection{Attributes and Colour} --- 272,284 ---- ensure that the cursor is positioned in some location where it won't be distracting; it can be confusing to have the cursor blinking at ! some apparently random location. ! ! If your application doesn't need a blinking cursor at all, you can ! call \function{curs_set(0)} to make it invisible. Equivalently, and ! for compatibility with older curses versions, there's a ! \function{leaveok(\var{bool})} function. When \var{bool} is true, the curses library will attempt to suppress the flashing cursor, and you won't need to worry about leaving it in odd locations. \subsection{Attributes and Colour} *************** *** 354,377 **** \end{verbatim} ! SVr4 curses also supports colour on those terminals that provide it, ! and Oliver Andrich's extended Python curses allows you to use the ! relevant functions. The most common such terminal is probably the ! Linux console, followed by colour xterms. To use colour, you must call the \function{start_color()} function soon after calling \function{initscr()}, to initialize the default ! colour set. Once that's done, the \function{has_colors()} function ! returns TRUE if the terminal in use can actually display colour. ! (Note that curses uses the American spelling 'color', instead of the ! Canadian/British spelling 'colour'; if you're like me, you'll have to ! resign yourself to misspelling it for the sake of these functions.) ! ! curses maintains a finite number of colour pairs, containing a ! foreground (or text) colour and a background colour. You can get the ! attribute value corresponding to a colour pair with the \function{COLOR_PAIR()} function; this can be bitwise-OR'ed with other attributes such as \constant{A_REVERSE}, but again, such combinations ! are not ! guaranteed to work on all terminals. An example, which displays a line of text using colour pair 1: --- 314,337 ---- \end{verbatim} ! The curses library also supports colour on those terminals that ! provide it, The most common such terminal is probably the Linux ! console, followed by colour xterms. To use colour, you must call the \function{start_color()} function soon after calling \function{initscr()}, to initialize the default ! colour set (the \function{curses.wrapper\wrapper()} function does this ! automatically). Once that's done, the \function{has_colors()} ! function returns TRUE if the terminal in use can actually display ! colour. (Note that curses uses the American spelling 'color', instead ! of the Canadian/British spelling 'colour'; if you're like me, you'll ! have to resign yourself to misspelling it for the sake of these ! functions.) ! ! The curses library maintains a finite number of colour pairs, ! containing a foreground (or text) colour and a background colour. You ! can get the attribute value corresponding to a colour pair with the \function{COLOR_PAIR()} function; this can be bitwise-OR'ed with other attributes such as \constant{A_REVERSE}, but again, such combinations ! are not guaranteed to work on all terminals. An example, which displays a line of text using colour pair 1: *************** *** 422,436 **** \section{User Input} ! curses offers only very simple input mechanisms. Windows have a ! \function{getch()} method that pauses, and waits for the user to hit a ! key, displaying it if \function{echo()} has been called earlier. You ! can optionally specify a coordinate to which the cursor should be ! moved before pausing. \function{getch()} returns an integer; if it's ! between 0 and 255, it represents the ASCII code of the key pressed. ! Values greater than 255 are special keys such as Page Up, Home, or the ! cursor keys. You can compare the value returned to constants such as \constant{curses.KEY_PPAGE}, \constant{curses.KEY_HOME}, or \constant{curses.KEY_LEFT}. Usually the main loop of your program ! might look like this: \begin{verbatim} --- 382,410 ---- \section{User Input} ! The curses library itself offers only very simple input mechanisms. ! Python's support adds a text-input widget that makes up some of the ! lack. ! ! The most common way to get input to a window is to use its ! \method{getch()} method. that pauses, and waits for the user to hit ! a key, displaying it if \function{echo()} has been called earlier. ! You can optionally specify a coordinate to which the cursor should be ! moved before pausing. ! ! It's possible to change this behavior with the method ! \method{nodelay()}. After \method{nodelay(1)}, \method{getch()} for ! the window becomes non-blocking and returns ERR (-1) when no input is ! ready. There's also a \function{halfdelay()} function, which can be ! used to (in effect) set a timer on each \method{getch()}; if no input ! becomes available within the number of milliseconds specified as the ! argument to \function{halfdelay()}, curses throws an exception. ! ! The \method{getch()} method returns an integer; if it's between 0 and ! 255, it represents the ASCII code of the key pressed. Values greater ! than 255 are special keys such as Page Up, Home, or the cursor keys. ! You can compare the value returned to constants such as \constant{curses.KEY_PPAGE}, \constant{curses.KEY_HOME}, or \constant{curses.KEY_LEFT}. Usually the main loop of your program ! will look something like this: \begin{verbatim} *************** *** 442,445 **** --- 416,427 ---- \end{verbatim} + The \module{curses.ascii} module supplies ASCII class membership + functions that take either integer or 1-character-string + arguments; these may be useful in writing more readable tests for + your command interprers. It also supplies conversion functions + that take either integer or 1-character-string arguments and return + the same type. For example, \function{curses.ascii.ctrl()} returns + the control character corresponding to its argument. + There's also a method to retrieve an entire string, \constant{getstr()}. It isn't used very often, because its *************** *** 454,493 **** s = stdscr.getstr(0,0, 15) \end{verbatim} - In future versions of this HOWTO, I'd like to include an - implementation of a fancy string entry function that allows full - editing. If you write such a function, send me a copy and it'll be - added to the next version of this document. - \section{For More Information} ! Again, I urge you to consult the manual pages for your curses ! implementation, whether it's ncurses or a commercial vendor's. The ! manual pages will document any quirks, and provide complete lists of ! all the functions, attributes, and \constant{ACS_*} characters ! available to you. Because the curses API is so large, some functions aren't supported in the Python interface, not because they're difficult to implement, but because no one has needed them yet. Feel free to add them and then ! submit a patch. ! Oliver Andrich's curses module comes with a demonstration program ! which displays a Life board, written by the author of this HOWTO; you ! may want to look at its code for more examples. If you write an ! interesting little program, feel free to contribute it as another ! demo. We can always use more of them! The ncurses FAQ: \url{http://www.clark.net/pub/dickey/ncurses/ncurses.faq.html} - Oliver Andrich's cursesmodule: \url{http://andrich.net/python/selfmade.html\#ncursesmodule} - Any other suggested references? - \section{Python curses Module Reference} - - I haven't yet written complete reference documentation for the curses - module; hopefully it will be added to a future version of this HOWTO. - \end{document} - --- 436,473 ---- s = stdscr.getstr(0,0, 15) \end{verbatim} + + The Python \module{curses.textpad} module supplies something better. + With it, you can turn a window into a text box that supports an + Emacs-like set of keybindings. Various methods of \class{Textbox} + class support editing with input validation and gathering the edit + results either with or without trailing spaces. See the library + documentation on \module{curses.textpad} for the details. \section{For More Information} ! This HOWTO didn't cover some advanced topics, such as screen-scraping ! or capturing mouse events from an xterm inatance. But the Python ! library page for the curses modules is now pretty complete. You ! should browse it next. ! ! If you're in doubt about the detailed behavior of any of the ncurses ! entry points, consult the manual pages for your curses implementation, ! whether it's ncurses or a proprietary Unix vendor's. The manual pages ! will document any quirks, and provide complete lists of all the ! functions, attributes, and \constant{ACS_*} characters available to ! you. Because the curses API is so large, some functions aren't supported in the Python interface, not because they're difficult to implement, but because no one has needed them yet. Feel free to add them and then ! submit a patch. Also, we don't yet have support for the menus or ! panels libraries associated with ncurses; feel free to add that. ! If you write an interesting little program, feel free to contribute it ! as another demo. We can always use more of them! The ncurses FAQ: \url{http://www.clark.net/pub/dickey/ncurses/ncurses.faq.html} Any other suggested references? \end{document} |
|
From: A.M. K. <aku...@us...> - 2000-08-09 18:02:48
|
Update of /cvsroot/py-howto/pyhowto In directory slayer.i.sourceforge.net:/tmp/cvs-serv14896 Modified Files: curses.tex Log Message: Dummy commit to test checkin email Index: curses.tex =================================================================== RCS file: /cvsroot/py-howto/pyhowto/curses.tex,v retrieving revision 1.4 retrieving revision 1.5 diff -C2 -r1.4 -r1.5 *** curses.tex 1999/12/09 12:58:18 1.4 --- curses.tex 2000/08/09 18:02:45 1.5 *************** *** 5,8 **** --- 5,9 ---- \release{1.0} + \author{A.M. Kuchling} \authoraddress{\email{am...@bi...}} |
