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...> - 2001-07-31 15:51:19
|
Update of /cvsroot/py-howto/pyhowto In directory usw-pr-cvs1:/tmp/cvs-serv5456 Modified Files: python-22.tex Log Message: Move C-level changes into a section of their own Add string.ascii_letters Remove duplicate MBCS paragraph Index: python-22.tex =================================================================== RCS file: /cvsroot/py-howto/pyhowto/python-22.tex,v retrieving revision 1.18 retrieving revision 1.19 diff -C2 -r1.18 -r1.19 *** python-22.tex 2001/07/31 01:11:36 1.18 --- python-22.tex 2001/07/31 15:51:16 1.19 *************** *** 575,607 **** name is \emph{not} going to be changed to \samp{rfc2822}. (Contributed by Barry Warsaw.) ! \end{itemize} %====================================================================== ! \section{Other Changes and Fixes} ! % XXX update the patch and bug figures as we go ! As usual there were a bunch of other improvements and bugfixes ! scattered throughout the source tree. A search through the CVS change ! logs finds there were 43 patches applied, and 77 bugs fixed; both ! figures are likely to be underestimates. Some of the more notable ! changes are: \begin{itemize} - \item Keyword arguments passed to builtin functions that don't take them - now cause a \exception{TypeError} exception to be raised, with the - message "\var{function} takes no keyword arguments". - - \item The code for the Mac OS port for Python, maintained by Jack - Jansen, is now kept in the main Python CVS tree. - - \item The new license introduced with Python 1.6 wasn't - GPL-compatible. This is fixed by some minor textual changes to the - 2.2 license, so Python can now be embedded inside a GPLed program - again. The license changes were also applied to the Python 2.0.1 - and 2.1.1 releases. - \item Profiling and tracing functions can now be implemented in C, which can operate at much higher speeds than Python-based functions --- 575,603 ---- name is \emph{not} going to be changed to \samp{rfc2822}. (Contributed by Barry Warsaw.) ! ! \item New constants \constant{ascii_letters}, ! \constant{ascii_lowercase}, and \constant{ascii_uppercase} were ! added to the \module{string} module. There were several modules in ! the standard library that used \constant{string.letters} to mean the ! ranges A-Za-z, but that assumption is incorrect when locales are in ! use, because \constant{string.letters} varies depending on the set ! of legal characters defined by the current locale. The buggy ! modules have all been fixed to use \constant{ascii_letters} instead. ! (Reported by an unknown person; fixed by Fred L. Drake, Jr.) ! \end{itemize} %====================================================================== ! \section{Interpreter Changes and Fixes} ! Some of the changes only affect people who deal with the Python ! interpreter at the C level, writing Python extension modules, ! embedding the interpreter, or just hacking on the interpreter itself. ! If you only write Python code, none of the changes described here will ! affect you very much. \begin{itemize} \item Profiling and tracing functions can now be implemented in C, which can operate at much higher speeds than Python-based functions *************** *** 624,633 **** states for a given interpreter. (Contributed by David Beazley.) ! % XXX is this explanation correct? ! \item When presented with a Unicode filename on Windows, Python will ! now correctly convert it to a string using the MBCS encoding. ! Filenames on Windows are a case where Python's choice of ASCII as ! the default encoding turns out to be an annoyance. \item When presented with a Unicode filename on Windows, Python will now convert it to an MBCS encoded string, as used by the Microsoft --- 620,670 ---- states for a given interpreter. (Contributed by David Beazley.) ! \item A new \samp{et} format sequence was added to ! \cfunction{PyArg_ParseTuple}; \samp{et} takes both a parameter and ! an encoding name, and converts the parameter to the given encoding ! if the parameter turns out to be a Unicode string, or leaves it ! alone if it's an 8-bit string, assuming it to already be in the ! desired encoding. This differs from the \samp{es} format character, ! which assumes that 8-bit strings are in Python's default ASCII ! encoding and converts them to the specified new encoding. ! (Contributed by M.-A. Lemburg, and used for the MBCS support on ! Windows described in the previous section.) ! ! \item Two new wrapper functions, \cfunction{PyOS_snprintf()} and ! \cfunction{PyOS_vsnprintf()} were added. which provide a cross-platform ! implementations for the relatively new snprintf()/vsnprintf() C lib ! APIs. In contrast to the standard sprintf() and vsprintf() C lib ! APIs, these versions apply bounds checking on the used buffer which ! enhances protection against buffer overruns. ! (Contributed by M.-A. Lemburg.) ! ! \end{itemize} ! + %====================================================================== + \section{Other Changes and Fixes} + + % XXX update the patch and bug figures as we go + As usual there were a bunch of other improvements and bugfixes + scattered throughout the source tree. A search through the CVS change + logs finds there were 43 patches applied, and 77 bugs fixed; both + figures are likely to be underestimates. Some of the more notable + changes are: + + \begin{itemize} + + \item Keyword arguments passed to builtin functions that don't take them + now cause a \exception{TypeError} exception to be raised, with the + message "\var{function} takes no keyword arguments". + + \item The code for the Mac OS port for Python, maintained by Jack + Jansen, is now kept in the main Python CVS tree. + + \item The new license introduced with Python 1.6 wasn't + GPL-compatible. This is fixed by some minor textual changes to the + 2.2 license, so Python can now be embedded inside a GPLed program + again. The license changes were also applied to the Python 2.0.1 + and 2.1.1 releases. + \item When presented with a Unicode filename on Windows, Python will now convert it to an MBCS encoded string, as used by the Microsoft *************** *** 636,648 **** annoyance. - This patch also adds \samp{et} as a format sequence to - \cfunction{PyArg_ParseTuple}; \samp{et} takes both a parameter and - an encoding name, and converts it to the given encoding if the - parameter turns out to be a Unicode string, or leaves it alone if - it's an 8-bit string, assuming it to already be in the desired - encoding. (This differs from the \samp{es} format character, which - assumes that 8-bit strings are in Python's default ASCII encoding - and converts them to the specified new encoding.) - (Contributed by Mark Hammond with assistance from Marc-Andr\'e Lemburg.) --- 673,676 ---- *************** *** 684,688 **** by \cfunction{dlopen()} using the \function{sys.getdlopenflags()} and \function{sys.setdlopenflags()} functions. (Contributed by Bram Stolk.) ! \end{itemize} --- 712,716 ---- by \cfunction{dlopen()} using the \function{sys.getdlopenflags()} and \function{sys.setdlopenflags()} functions. (Contributed by Bram Stolk.) ! \end{itemize} |
From: A.M. K. <aku...@us...> - 2001-07-31 01:11:39
|
Update of /cvsroot/py-howto/pyhowto In directory usw-pr-cvs1:/tmp/cvs-serv25014 Modified Files: python-22.tex Log Message: Rewrite MBCS paragraph following MH's suggestions, and credit him Note new Windows installer Index: python-22.tex =================================================================== RCS file: /cvsroot/py-howto/pyhowto/python-22.tex,v retrieving revision 1.17 retrieving revision 1.18 diff -C2 -r1.17 -r1.18 *** python-22.tex 2001/07/20 18:34:34 1.17 --- python-22.tex 2001/07/31 01:11:36 1.18 *************** *** 630,633 **** --- 630,639 ---- the default encoding turns out to be an annoyance. + \item When presented with a Unicode filename on Windows, Python will + now convert it to an MBCS encoded string, as used by the Microsoft + file APIs. As MBCS is explicitly used by the file APIs, Python's + choice of ASCII as the default encoding turns out to be an + annoyance. + This patch also adds \samp{et} as a format sequence to \cfunction{PyArg_ParseTuple}; \samp{et} takes both a parameter and *************** *** 669,672 **** --- 675,683 ---- to a number of patches contributed by Stephen Hansen. + \item Another Windows enhancement: Wise Solutions generously offered + PythonLabs use of their InstallerMaster 8.1 system. Earlier + PythonLabs Windows installers used Wise 5.0a, which was beginning to + show its age. (Packaged up by Tim Peters.) + \item On platforms where Python uses the C \cfunction{dlopen()} function to load extension modules, it's now possible to set the flags used *************** *** 682,686 **** The author would like to thank the following people for offering suggestions and corrections to various drafts of this article: Fred ! Bremmer, Fred L. Drake, Jr., Marc-Andr\'e Lemburg, Tim Peters, Neil Schemenauer, Guido van Rossum. --- 693,697 ---- The author would like to thank the following people for offering suggestions and corrections to various drafts of this article: Fred ! Bremmer, Fred L. Drake, Jr., Mark Hammond, Marc-Andr\'e Lemburg, Tim Peters, Neil Schemenauer, Guido van Rossum. |
From: A.M. K. <aku...@us...> - 2001-07-20 18:34:38
|
Update of /cvsroot/py-howto/pyhowto In directory usw-pr-cvs1:/tmp/cvs-serv22040 Modified Files: python-22.tex Log Message: More Unicode corrections from MAL to match a post-2.2a1 change Mention additional new imaplib.py features (Don't expect to see an updated version of the Web page until around the 28th of July. Vacation time!) Index: python-22.tex =================================================================== RCS file: /cvsroot/py-howto/pyhowto/python-22.tex,v retrieving revision 1.16 retrieving revision 1.17 diff -C2 -r1.16 -r1.17 *** python-22.tex 2001/07/19 14:59:53 1.16 --- python-22.tex 2001/07/20 18:34:34 1.17 *************** *** 340,370 **** Python's Unicode support has been enhanced a bit in 2.2. Unicode ! strings are usually stored as UTF-16, as 16-bit unsigned integers. Python 2.2 can also be compiled to use UCS-4, 32-bit unsigned integers, as its internal encoding by supplying \longprogramopt{enable-unicode=ucs4} to the configure script. When built to use UCS-4 (a ``wide Python''), the interpreter can natively ! handle Unicode characters from U+000000 to U+110000. The range of ! legal values for the \function{unichr()} function has been expanded; ! it used to only accept values up to 65535, but in 2.2 will accept ! values from 0 to 0x110000. Using a ``narrow Python'', an interpreter ! compiled to use UTF-16, values greater than 65535 will result in ! \function{unichr()} returning a string of length 2: - \begin{verbatim} - >>> s = unichr(65536) - >>> s - u'\ud800\udc00' - >>> len(s) - 2 - \end{verbatim} - - This possibly-confusing behaviour, breaking the intuitive invariant - that \function{chr()} and\function{unichr()} always return strings of - length 1, may be changed later in 2.2 depending on public reaction. - All this is the province of the still-unimplemented PEP 261, ``Support for `wide' Unicode characters''; consult it for further details, and ! please offer comments and suggestions on the proposal it describes. Another change is much simpler to explain. Since their introduction, --- 340,359 ---- Python's Unicode support has been enhanced a bit in 2.2. Unicode ! strings are usually stored as UCS-2, as 16-bit unsigned integers. Python 2.2 can also be compiled to use UCS-4, 32-bit unsigned integers, as its internal encoding by supplying \longprogramopt{enable-unicode=ucs4} to the configure script. When built to use UCS-4 (a ``wide Python''), the interpreter can natively ! handle Unicode characters from U+000000 to U+110000, so the range of ! legal values for the \function{unichr()} function is expanded ! accordingly. Using an interpreter compiled to use UCS-2 (a ``narrow ! Python''), values greater than 65535 will still cause ! \function{unichr()} to raise a \exception{ValueError} exception. All this is the province of the still-unimplemented PEP 261, ``Support for `wide' Unicode characters''; consult it for further details, and ! please offer comments on the PEP and on your experiences with the ! 2.2 alpha releases. ! % XXX update previous line once 2.2 reaches beta. Another change is much simpler to explain. Since their introduction, *************** *** 577,583 **** contributed by Martin von L\"owis.) ! \item The \module{imaplib} module now has support for the IMAP ! NAMESPACE extension defined in \rfc{2342}. (Contributed by Michel ! Pelletier.) \item The \module{rfc822} module's parsing of email addresses is --- 566,573 ---- contributed by Martin von L\"owis.) ! \item The \module{imaplib} module, maintained by Piers Lauder, has ! support for several new extensions: the NAMESPACE extension defined ! in \rfc{2342}, SORT, GETACL and SETACL. (Contributed by Anthony ! Baxter and Michel Pelletier.) \item The \module{rfc822} module's parsing of email addresses is |
From: A.M. K. <aku...@us...> - 2001-07-20 03:22:05
|
Update of /cvsroot/py-howto/pyhowto In directory usw-pr-cvs1:/tmp/cvs-serv17756 Modified Files: python-21.tex Log Message: Bump release number to 1.00, while I'm at it Index: python-21.tex =================================================================== RCS file: /cvsroot/py-howto/pyhowto/python-21.tex,v retrieving revision 1.26 retrieving revision 1.27 diff -C2 -r1.26 -r1.27 *** python-21.tex 2001/07/19 00:29:48 1.26 --- python-21.tex 2001/07/20 03:22:00 1.27 *************** *** 6,10 **** \title{What's New in Python 2.1} ! \release{0.99} \author{A.M. Kuchling} \authoraddress{\email{am...@bi...}} --- 6,10 ---- \title{What's New in Python 2.1} ! \release{1.00} \author{A.M. Kuchling} \authoraddress{\email{am...@bi...}} |
From: A.M. K. <aku...@us...> - 2001-07-19 14:59:56
|
Update of /cvsroot/py-howto/pyhowto In directory usw-pr-cvs1:/tmp/cvs-serv17509 Modified Files: python-22.tex Log Message: Revise the Unicode section after getting comments from MAL, GvR, and others. Add new low-level API for interpreter introspection Bump version number. Index: python-22.tex =================================================================== RCS file: /cvsroot/py-howto/pyhowto/python-22.tex,v retrieving revision 1.15 retrieving revision 1.16 diff -C2 -r1.15 -r1.16 *** python-22.tex 2001/07/19 01:48:08 1.15 --- python-22.tex 2001/07/19 14:59:53 1.16 *************** *** 4,8 **** \title{What's New in Python 2.2} ! \release{0.03} \author{A.M. Kuchling} \authoraddress{\email{aku...@me...}} --- 4,8 ---- \title{What's New in Python 2.2} ! \release{0.04} \author{A.M. Kuchling} \authoraddress{\email{aku...@me...}} *************** *** 340,371 **** Python's Unicode support has been enhanced a bit in 2.2. Unicode ! strings are usually stored as UCS-2, as 16-bit unsigned integers. Python 2.2 can also be compiled to use UCS-4, 32-bit unsigned integers, as its internal encoding by supplying \longprogramopt{enable-unicode=ucs4} to the configure script. When ! built to use UCS-4, in theory Python could handle Unicode characters ! from U-00000000 to U-7FFFFFFF. Being able to use UCS-4 internally is ! a necessary step to do that, but it's not the only step, and in Python ! 2.2alpha1 the work isn't complete yet. For example, the ! \function{unichr()} function still only accepts values from 0 to ! 65535, and there's no \code{\e U} notation for embedding characters ! greater than 65535 in a Unicode string literal. All this is the ! province of the still-unimplemented PEP 261, ``Support for `wide' ! Unicode characters''; consult it for further details, and please offer ! comments and suggestions on the proposal it describes. ! ! Another change is much simpler to explain. ! Since their introduction, Unicode strings have supported an ! \method{encode()} method to convert the string to a selected encoding ! such as UTF-8 or Latin-1. A symmetric ! \method{decode(\optional{\var{encoding}})} method has been added to ! both 8-bit and Unicode strings in 2.2, which assumes that the string ! is in the specified encoding and decodes it. This means that ! \method{encode()} and \method{decode()} can be called on both types of ! strings, and can be used for tasks not directly related to Unicode. ! For example, codecs have been added for UUencoding, MIME's base-64 ! encoding, and compression with the \module{zlib} module. \begin{verbatim} >>> s = """Here is a lengthy piece of redundant, overly verbose, ... and repetitive text. --- 340,385 ---- Python's Unicode support has been enhanced a bit in 2.2. Unicode ! strings are usually stored as UTF-16, as 16-bit unsigned integers. Python 2.2 can also be compiled to use UCS-4, 32-bit unsigned integers, as its internal encoding by supplying \longprogramopt{enable-unicode=ucs4} to the configure script. When ! built to use UCS-4 (a ``wide Python''), the interpreter can natively ! handle Unicode characters from U+000000 to U+110000. The range of ! legal values for the \function{unichr()} function has been expanded; ! it used to only accept values up to 65535, but in 2.2 will accept ! values from 0 to 0x110000. Using a ``narrow Python'', an interpreter ! compiled to use UTF-16, values greater than 65535 will result in ! \function{unichr()} returning a string of length 2: \begin{verbatim} + >>> s = unichr(65536) + >>> s + u'\ud800\udc00' + >>> len(s) + 2 + \end{verbatim} + + This possibly-confusing behaviour, breaking the intuitive invariant + that \function{chr()} and\function{unichr()} always return strings of + length 1, may be changed later in 2.2 depending on public reaction. + + All this is the province of the still-unimplemented PEP 261, ``Support + for `wide' Unicode characters''; consult it for further details, and + please offer comments and suggestions on the proposal it describes. + + Another change is much simpler to explain. Since their introduction, + Unicode strings have supported an \method{encode()} method to convert + the string to a selected encoding such as UTF-8 or Latin-1. A + symmetric \method{decode(\optional{\var{encoding}})} method has been + added to 8-bit strings (though not to Unicode strings) in 2.2. + \method{decode()} assumes that the string is in the specified encoding + and decodes it, returning whatever is returned by the codec. + + Using this new feature, codecs have been added for tasks not directly + related to Unicode. For example, codecs have been added for + uu-encoding, MIME's base64 encoding, and compression with the + \module{zlib} module: + + \begin{verbatim} >>> s = """Here is a lengthy piece of redundant, overly verbose, ... and repetitive text. *************** *** 611,614 **** --- 625,637 ---- L. Drake, Jr.) + \item Another low-level API, primarily of interest to implementors + of Python debuggers and development tools, was added. + \cfunction{PyInterpreterState_Head()} and + \cfunction{PyInterpreterState_Next()} let a caller walk through all + the existing interpreter objects; + \cfunction{PyInterpreterState_ThreadHead()} and + \cfunction{PyThreadState_Next()} allow looping over all the thread + states for a given interpreter. (Contributed by David Beazley.) + % XXX is this explanation correct? \item When presented with a Unicode filename on Windows, Python will *************** *** 669,673 **** The author would like to thank the following people for offering suggestions and corrections to various drafts of this article: Fred ! Bremmer, Fred L. Drake, Jr., Tim Peters, Neil Schemenauer. \end{document} --- 692,697 ---- The author would like to thank the following people for offering suggestions and corrections to various drafts of this article: Fred ! Bremmer, Fred L. Drake, Jr., Marc-Andr\'e Lemburg, ! Tim Peters, Neil Schemenauer, Guido van Rossum. \end{document} |
From: A.M. K. <aku...@us...> - 2001-07-19 01:48:12
|
Update of /cvsroot/py-howto/pyhowto In directory usw-pr-cvs1:/tmp/cvs-serv12586 Modified Files: python-22.tex Log Message: Fill out the Unicode section, somewhat uncertainly Index: python-22.tex =================================================================== RCS file: /cvsroot/py-howto/pyhowto/python-22.tex,v retrieving revision 1.14 retrieving revision 1.15 diff -C2 -r1.14 -r1.15 *** python-22.tex 2001/07/19 01:19:59 1.14 --- python-22.tex 2001/07/19 01:48:08 1.15 *************** *** 341,349 **** Python's Unicode support has been enhanced a bit in 2.2. Unicode strings are usually stored as UCS-2, as 16-bit unsigned integers. ! Python 2.2 can also be compiled to use UCS-4, 32-bit unsigned integers ! by supplying \longprogramopt{enable-unicode=ucs4} to the configure script. ! XXX explain surrogates? I have to figure out what the changes mean to users. ! Since their introduction, Unicode strings have supported an \method{encode()} method to convert the string to a selected encoding --- 341,359 ---- Python's Unicode support has been enhanced a bit in 2.2. Unicode strings are usually stored as UCS-2, as 16-bit unsigned integers. ! Python 2.2 can also be compiled to use UCS-4, 32-bit unsigned ! integers, as its internal encoding by supplying ! \longprogramopt{enable-unicode=ucs4} to the configure script. When ! built to use UCS-4, in theory Python could handle Unicode characters ! from U-00000000 to U-7FFFFFFF. Being able to use UCS-4 internally is ! a necessary step to do that, but it's not the only step, and in Python ! 2.2alpha1 the work isn't complete yet. For example, the ! \function{unichr()} function still only accepts values from 0 to ! 65535, and there's no \code{\e U} notation for embedding characters ! greater than 65535 in a Unicode string literal. All this is the ! province of the still-unimplemented PEP 261, ``Support for `wide' ! Unicode characters''; consult it for further details, and please offer ! comments and suggestions on the proposal it describes. ! Another change is much simpler to explain. Since their introduction, Unicode strings have supported an \method{encode()} method to convert the string to a selected encoding *************** *** 375,382 **** 'furrfu' \end{verbatim} ! References: http://mail.python.org/pipermail/i18n-sig/2001-June/001107.html ! and following thread. %====================================================================== --- 385,399 ---- 'furrfu' \end{verbatim} + + \method{encode()} and \method{decode()} were implemented by + Marc-Andr\'e Lemburg. The changes to support using UCS-4 internally + were implemented by Fredrik Lundh and Martin von L\"owis. + + \begin{seealso} ! \seepep{261}{Support for `wide' Unicode characters}{PEP written by ! Paul Prescod. Not yet accepted or fully implemented.} + \end{seealso} %====================================================================== |
From: A.M. K. <aku...@us...> - 2001-07-19 01:20:02
|
Update of /cvsroot/py-howto/pyhowto In directory usw-pr-cvs1:/tmp/cvs-serv8489 Modified Files: python-22.tex Log Message: Finish the "Other changes" section Bump version number Insert a few blank lines here and there Index: python-22.tex =================================================================== RCS file: /cvsroot/py-howto/pyhowto/python-22.tex,v retrieving revision 1.13 retrieving revision 1.14 diff -C2 -r1.13 -r1.14 *** python-22.tex 2001/07/17 18:25:01 1.13 --- python-22.tex 2001/07/19 01:19:59 1.14 *************** *** 4,8 **** \title{What's New in Python 2.2} ! \release{0.02} \author{A.M. Kuchling} \authoraddress{\email{aku...@me...}} --- 4,8 ---- \title{What's New in Python 2.2} ! \release{0.03} \author{A.M. Kuchling} \authoraddress{\email{aku...@me...}} *************** *** 34,37 **** --- 34,38 ---- The final release of Python 2.2 is planned for October 2001. + %====================================================================== % It looks like this set of changes will likely get into 2.2, *************** *** 41,44 **** --- 42,47 ---- %XXX + % GvR's description at http://www.python.org/2.2/descrintro.html + %\begin{seealso} *************** *** 48,51 **** --- 51,55 ---- %\end{seealso} + %====================================================================== \section{PEP 234: Iterators} *************** *** 184,187 **** --- 188,192 ---- \end{seealso} + %====================================================================== \section{PEP 255: Simple Generators} *************** *** 330,333 **** --- 335,339 ---- \end{seealso} + %====================================================================== \section{Unicode Changes} *************** *** 340,346 **** XXX explain surrogates? I have to figure out what the changes mean to users. ! Since their introduction, Unicode strings (XXX and regular strings in ! 2.1?) have supported an \method{encode()} method to convert the ! string to a selected encoding such as UTF-8 or Latin-1. A symmetric \method{decode(\optional{\var{encoding}})} method has been added to both 8-bit and Unicode strings in 2.2, which assumes that the string --- 346,352 ---- XXX explain surrogates? I have to figure out what the changes mean to users. ! Since their introduction, Unicode strings have supported an ! \method{encode()} method to convert the string to a selected encoding ! such as UTF-8 or Latin-1. A symmetric \method{decode(\optional{\var{encoding}})} method has been added to both 8-bit and Unicode strings in 2.2, which assumes that the string *************** *** 373,376 **** --- 379,383 ---- and following thread. + %====================================================================== \section{PEP 227: Nested Scopes} *************** *** 554,560 **** \section{Other Changes and Fixes} As usual there were a bunch of other improvements and bugfixes scattered throughout the source tree. A search through the CVS change ! logs finds there were XXX patches applied, and XXX bugs fixed; both figures are likely to be underestimates. Some of the more notable changes are: --- 561,568 ---- \section{Other Changes and Fixes} + % XXX update the patch and bug figures as we go As usual there were a bunch of other improvements and bugfixes scattered throughout the source tree. A search through the CVS change ! logs finds there were 43 patches applied, and 77 bugs fixed; both figures are likely to be underestimates. Some of the more notable changes are: *************** *** 586,589 **** --- 594,615 ---- L. Drake, Jr.) + % XXX is this explanation correct? + \item When presented with a Unicode filename on Windows, Python will + now correctly convert it to a string using the MBCS encoding. + Filenames on Windows are a case where Python's choice of ASCII as + the default encoding turns out to be an annoyance. + + This patch also adds \samp{et} as a format sequence to + \cfunction{PyArg_ParseTuple}; \samp{et} takes both a parameter and + an encoding name, and converts it to the given encoding if the + parameter turns out to be a Unicode string, or leaves it alone if + it's an 8-bit string, assuming it to already be in the desired + encoding. (This differs from the \samp{es} format character, which + assumes that 8-bit strings are in Python's default ASCII encoding + and converts them to the specified new encoding.) + + (Contributed by Mark Hammond with assistance from Marc-Andr\'e + Lemburg.) + \item The \file{Tools/scripts/ftpmirror.py} script now parses a \file{.netrc} file, if you have one. *************** *** 601,637 **** \cfunction{PyRange_New()} function, \samp{repeat}, has also been deprecated. - - \item On Windows, Python can now be compiled with Borland C thanks - to a number of patches contribued by Stephen Hansen. ! \item XXX C API: Reorganization of object calling ! The \cfunction{call_object()} function, originally in \file{ceval.c}, ! begins a new life as the official API \cfunction{PyObject_Call()}. It ! is also much simplified: all it does is call the \member{tp_call} ! slot, or raise an exception if that's \NULL. ! ! %The subsidiary functions (call_eval_code2(), call_cfunction(), ! %call_instance(), and call_method()) have all been moved to the file ! %implementing their particular object type, renamed according to the ! %local convention, and added to the type's tp_call slot. Note that ! %call_eval_code2() became function_call(); the tp_slot for class ! %objects now simply points to PyInstance_New(), which already has the ! %correct signature. ! ! %Because of these moves, there are some more new APIs that expose ! %helpers in ceval.c that are now needed outside: PyEval_GetFuncName(), ! %PyEval_GetFuncDesc(), PyEval_EvalCodeEx() (formerly get_func_name(), ! %get_func_desc(), and eval_code2(). ! ! \item XXX Add support for Windows using "mbcs" as the default ! Unicode encoding when dealing with the file system. As discussed on ! python-dev and in patch 410465. ! \item XXX Lots of patches to dictionaries; measure performance ! improvement, if any. \end{itemize} - --- 627,648 ---- \cfunction{PyRange_New()} function, \samp{repeat}, has also been deprecated. ! \item There were a bunch of patches to the dictionary ! implementation, mostly to fix potential core dumps if a dictionary ! contains objects that sneakily changed their hash value, or mutated ! the dictionary they were contained in. For a while python-dev fell ! into a gentle rhythm of Michael Hudson finding a case that dump ! core, Tim Peters fixing it, Michael finding another case, and round ! and round it went. ! \item On Windows, Python can now be compiled with Borland C thanks ! to a number of patches contributed by Stephen Hansen. ! \item On platforms where Python uses the C \cfunction{dlopen()} function ! to load extension modules, it's now possible to set the flags used ! by \cfunction{dlopen()} using the \function{sys.getdlopenflags()} and ! \function{sys.setdlopenflags()} functions. (Contributed by Bram Stolk.) \end{itemize} |
From: A.M. K. <aku...@us...> - 2001-07-19 00:29:51
|
Update of /cvsroot/py-howto/pyhowto In directory usw-pr-cvs1:/tmp/cvs-serv939 Modified Files: python-21.tex Log Message: Remove note about this being a draft document. Note the actual date of 2.1's release Index: python-21.tex =================================================================== RCS file: /cvsroot/py-howto/pyhowto/python-21.tex,v retrieving revision 1.25 retrieving revision 1.26 diff -C2 -r1.25 -r1.26 *** python-21.tex 2001/04/16 02:27:53 1.25 --- python-21.tex 2001/07/19 00:29:48 1.26 *************** *** 14,23 **** \section{Introduction} - {\large This document is a draft, and is subject to change until the - final version of Python 2.1 is released. Currently it is up to date - for Python 2.1 release candidate~1. Please send any comments, bug - reports, or questions, no matter how minor, to - \email{am...@bi...}. } - It's that time again... time for a new Python release, Python 2.1. One recent goal of the Python development team has been to accelerate --- 14,17 ---- *************** *** 38,42 **** more details about any new feature that particularly interests you. ! The final release of Python 2.1 is planned for April 2001. %====================================================================== --- 32,36 ---- more details about any new feature that particularly interests you. ! The final release of Python 2.1 was made on April 17, 2001. %====================================================================== |
From: A.M. K. <aku...@us...> - 2001-07-17 18:25:05
|
Update of /cvsroot/py-howto/pyhowto In directory usw-pr-cvs1:/tmp/cvs-serv19910 Modified Files: python-22.tex Log Message: Delete sentence fragment (noted by Fred Bremmer) Index: python-22.tex =================================================================== RCS file: /cvsroot/py-howto/pyhowto/python-22.tex,v retrieving revision 1.12 retrieving revision 1.13 diff -C2 -r1.12 -r1.13 *** python-22.tex 2001/07/17 14:54:07 1.12 --- python-22.tex 2001/07/17 18:25:01 1.13 *************** *** 269,276 **** be done by setting \code{self.count} to 0, and having the \method{next()} method increment \code{self.count} and return it. ! because it would be easy to write a Python class. However, for a ! moderately complicated generator, writing a corresponding class would ! be much messier. \file{Lib/test/test_generators.py} contains a number ! of more interesting examples. The simplest one implements an in-order traversal of a tree using generators recursively. --- 269,276 ---- be done by setting \code{self.count} to 0, and having the \method{next()} method increment \code{self.count} and return it. ! However, for a moderately complicated generator, writing a ! corresponding class would be much messier. ! \file{Lib/test/test_generators.py} contains a number of more ! interesting examples. The simplest one implements an in-order traversal of a tree using generators recursively. *************** *** 641,645 **** The author would like to thank the following people for offering suggestions and corrections to various drafts of this article: Fred ! L. Drake, Jr., Tim Peters, Neil Schemenauer. \end{document} --- 641,645 ---- The author would like to thank the following people for offering suggestions and corrections to various drafts of this article: Fred ! Bremmer, Fred L. Drake, Jr., Tim Peters, Neil Schemenauer. \end{document} |
From: Fred L. D. <fd...@us...> - 2001-07-17 14:54:10
|
Update of /cvsroot/py-howto/pyhowto In directory usw-pr-cvs1:/tmp/cvs-serv23473 Modified Files: python-22.tex Log Message: Now we're picking nits: get my name right! ;-) Index: python-22.tex =================================================================== RCS file: /cvsroot/py-howto/pyhowto/python-22.tex,v retrieving revision 1.11 retrieving revision 1.12 diff -C2 -r1.11 -r1.12 *** python-22.tex 2001/07/17 14:50:31 1.11 --- python-22.tex 2001/07/17 14:54:07 1.12 *************** *** 641,645 **** The author would like to thank the following people for offering suggestions and corrections to various drafts of this article: Fred ! L. Drake, Tim Peters, Neil Schemenauer. \end{document} --- 641,645 ---- The author would like to thank the following people for offering suggestions and corrections to various drafts of this article: Fred ! L. Drake, Jr., Tim Peters, Neil Schemenauer. \end{document} |
From: A.M. K. <aku...@us...> - 2001-07-17 14:50:34
|
Update of /cvsroot/py-howto/pyhowto In directory usw-pr-cvs1:/tmp/cvs-serv22510 Modified Files: python-22.tex Log Message: Add FLD to credit list Correct grammatical error Index: python-22.tex =================================================================== RCS file: /cvsroot/py-howto/pyhowto/python-22.tex,v retrieving revision 1.10 retrieving revision 1.11 diff -C2 -r1.10 -r1.11 *** python-22.tex 2001/07/17 13:55:33 1.10 --- python-22.tex 2001/07/17 14:50:31 1.11 *************** *** 136,140 **** dict} is now equivalent to \code{dict.has_key(\var{key})}. Calling \function{iter()} on a dictionary will return an iterator ! which loops over their keys: \begin{verbatim} --- 136,140 ---- dict} is now equivalent to \code{dict.has_key(\var{key})}. Calling \function{iter()} on a dictionary will return an iterator ! which loops over its keys: \begin{verbatim} *************** *** 640,644 **** The author would like to thank the following people for offering ! suggestions on various drafts of this article: Tim Peters, Neil Schemenauer. \end{document} --- 640,645 ---- The author would like to thank the following people for offering ! suggestions and corrections to various drafts of this article: Fred ! L. Drake, Tim Peters, Neil Schemenauer. \end{document} |
From: Fred L. D. <fd...@us...> - 2001-07-17 13:55:36
|
Update of /cvsroot/py-howto/pyhowto In directory usw-pr-cvs1:/tmp/cvs-serv4354 Modified Files: python-22.tex Log Message: Cleaned up a number of minor nits, use markup a little more consistently. Index: python-22.tex =================================================================== RCS file: /cvsroot/py-howto/pyhowto/python-22.tex,v retrieving revision 1.9 retrieving revision 1.10 diff -C2 -r1.9 -r1.10 *** python-22.tex 2001/07/17 12:48:48 1.9 --- python-22.tex 2001/07/17 13:55:33 1.10 *************** *** 24,29 **** the new features, but instead provides a convenient overview of the new features. For full details, you should refer to 2.2 documentation ! such as the Library Reference and the Reference Guide, or to the PEP ! for a particular new feature. The final release of Python 2.2 is planned for October 2001. --- 24,34 ---- the new features, but instead provides a convenient overview of the new features. For full details, you should refer to 2.2 documentation ! such as the ! \citetitle[http://python.sourceforge.net/devel-docs/lib/lib.html]{Python ! Library Reference} and the ! \citetitle[http://python.sourceforge.net/devel-docs/ref/ref.html]{Python ! Reference Manual}, or to the PEP for a particular new feature. ! % These \citetitle marks should get the python.org URLs for the final ! % release, just as soon as the docs are published there. The final release of Python 2.2 is planned for October 2001. *************** *** 75,80 **** simple. A new built-in function, \function{iter(obj)}, returns an iterator for the object \var{obj}. (It can also take two arguments: ! \code{iter(\var{C}, \var{sentinel})} will call the callable \var{C}, until it ! returns \var{sentinel}, which will signal that the iterator is done. This form probably won't be used very often.) Python classes can define an \method{__iter__()} method, which should --- 80,86 ---- simple. A new built-in function, \function{iter(obj)}, returns an iterator for the object \var{obj}. (It can also take two arguments: ! \code{iter(\var{C}, \var{sentinel})} will call the callable \var{C}, ! until it returns \var{sentinel}, which will signal that the iterator ! is done. This form probably won't be used very often.) Python classes can define an \method{__iter__()} method, which should *************** *** 129,133 **** \keyword{in} operator now works on dictionaries, so \code{\var{key} in dict} is now equivalent to \code{dict.has_key(\var{key})}. ! Calling \function{iter()} on a dictionary will return an iterator which loops over their keys: \begin{verbatim} --- 135,140 ---- \keyword{in} operator now works on dictionaries, so \code{\var{key} in dict} is now equivalent to \code{dict.has_key(\var{key})}. ! Calling \function{iter()} on a dictionary will return an iterator ! which loops over their keys: \begin{verbatim} *************** *** 167,171 **** Note that you can only go forward in an iterator; there's no way to get the previous element, reset the iterator, or make a copy of it. ! An iterator object could provide such additional capabilities, but the iterator protocol only requires a \method{next()} method. \begin{seealso} --- 174,179 ---- Note that you can only go forward in an iterator; there's no way to get the previous element, reset the iterator, or make a copy of it. ! An iterator object could provide such additional capabilities, but the ! iterator protocol only requires a \method{next()} method. \begin{seealso} *************** *** 461,465 **** used in most Python code (and when it is used, it's often a sign of a poor design anyway). - %\end{seealso} \begin{seealso} --- 469,472 ---- *************** *** 502,506 **** \end{verbatim} ! See \url{http://www.xmlrpc.com} for more information about XML-RPC. \item The \module{socket} module can be compiled to support IPv6; --- 509,513 ---- \end{verbatim} ! See \url{http://www.xmlrpc.com/} for more information about XML-RPC. \item The \module{socket} module can be compiled to support IPv6; *************** *** 536,540 **** Pelletier.) ! \item The \module{rfc822} module's parsing of e-mail addresses is now compliant with \rfc{2822}, an update to \rfc{822}. The module's name is \emph{not} going to be changed to \samp{rfc2822}. --- 543,547 ---- Pelletier.) ! \item The \module{rfc822} module's parsing of email addresses is now compliant with \rfc{2822}, an update to \rfc{822}. The module's name is \emph{not} going to be changed to \samp{rfc2822}. *************** *** 559,563 **** message "\var{function} takes no keyword arguments". ! \item The code for the MacOS port for Python, maintained by Jack Jansen, is now kept in the main Python CVS tree. --- 566,570 ---- message "\var{function} takes no keyword arguments". ! \item The code for the Mac OS port for Python, maintained by Jack Jansen, is now kept in the main Python CVS tree. *************** *** 576,580 **** The existing \function{sys.setprofile()} and \function{sys.settrace()} functions still exist, and have simply ! been changed to use the new C-level interface. \item The \file{Tools/scripts/ftpmirror.py} script --- 583,588 ---- The existing \function{sys.setprofile()} and \function{sys.settrace()} functions still exist, and have simply ! been changed to use the new C-level interface. (Contributed by Fred ! L. Drake, Jr.) \item The \file{Tools/scripts/ftpmirror.py} script *************** *** 599,606 **** \item XXX C API: Reorganization of object calling ! The call_object() ! function, originally in ceval.c, begins a new life as the official ! API PyObject_Call(). It is also much simplified: all it does is call ! the tp_call slot, or raise an exception if that's NULL. %The subsidiary functions (call_eval_code2(), call_cfunction(), --- 607,614 ---- \item XXX C API: Reorganization of object calling ! The \cfunction{call_object()} function, originally in \file{ceval.c}, ! begins a new life as the official API \cfunction{PyObject_Call()}. It ! is also much simplified: all it does is call the \member{tp_call} ! slot, or raise an exception if that's \NULL. %The subsidiary functions (call_eval_code2(), call_cfunction(), *************** *** 621,625 **** python-dev and in patch 410465. ! \item XXX Lots of patches to dictionaries; measure performance improvement, if any. \end{itemize} --- 629,634 ---- python-dev and in patch 410465. ! \item XXX Lots of patches to dictionaries; measure performance ! improvement, if any. \end{itemize} |
From: A.M. K. <aku...@us...> - 2001-07-17 12:48:52
|
Update of /cvsroot/py-howto/pyhowto In directory usw-pr-cvs1:/tmp/cvs-serv15684 Modified Files: python-22.tex Log Message: Minor rewrites to iterator and generator sections Credit both Neil and Tim for generators Fix indentation of a few paragraphs Index: python-22.tex =================================================================== RCS file: /cvsroot/py-howto/pyhowto/python-22.tex,v retrieving revision 1.8 retrieving revision 1.9 diff -C2 -r1.8 -r1.9 *** python-22.tex 2001/07/16 14:35:52 1.8 --- python-22.tex 2001/07/17 12:48:48 1.9 *************** *** 83,87 **** iterators will usually be their own iterators. Extension types implemented in C can implement a \code{tp_iter} function in order to ! return an iterator, too. So what do iterators do? They have one required method, --- 83,88 ---- iterators will usually be their own iterators. Extension types implemented in C can implement a \code{tp_iter} function in order to ! return an iterator, and extension types that want to behave as ! iterators can define a \code{tp_iternext} function. So what do iterators do? They have one required method, *************** *** 202,218 **** function containing a \keyword{yield} statement is a generator function; this is detected by Python's bytecode compiler which ! compiles the function specially. When you call a generator function, ! it doesn't return a single value; instead it returns a generator ! object that supports the iterator interface. On executing the ! \keyword{yield} statement, the generator outputs the value of ! \code{i}, similar to a \keyword{return} statement. The big difference ! between \keyword{yield} and a \keyword{return} statement is that, on ! reaching a \keyword{yield} the generator's state of execution is ! suspended and local variables are preserved. On the next call to the ! generator's \code{.next()} method, the function will resume executing ! immediately after the \keyword{yield} statement. (For complicated ! reasons, the \keyword{yield} statement isn't allowed inside the ! \keyword{try} block of a \code{try...finally} statement; read PEP 255 ! for a full explanation of the interaction between \keyword{yield} and exceptions.) --- 203,225 ---- function containing a \keyword{yield} statement is a generator function; this is detected by Python's bytecode compiler which ! compiles the function specially. Because a new keyword was ! introduced, generators must be explicitly enabled in a module by ! including a \code{from __future__ import generators} statement near ! the top of the module's source code. In Python 2.3 this statement ! will become unnecessary. ! ! When you call a generator function, it doesn't return a single value; ! instead it returns a generator object that supports the iterator ! interface. On executing the \keyword{yield} statement, the generator ! outputs the value of \code{i}, similar to a \keyword{return} ! statement. The big difference between \keyword{yield} and a ! \keyword{return} statement is that, on reaching a \keyword{yield} the ! generator's state of execution is suspended and local variables are ! preserved. On the next call to the generator's \code{.next()} method, ! the function will resume executing immediately after the ! \keyword{yield} statement. (For complicated reasons, the ! \keyword{yield} statement isn't allowed inside the \keyword{try} block ! of a \code{try...finally} statement; read PEP 255 for a full ! explanation of the interaction between \keyword{yield} and exceptions.) *************** *** 241,254 **** Inside a generator function, the \keyword{return} statement can only ! be used without a value, and is equivalent to raising the ! \exception{StopIteration} exception; afterwards the generator cannot ! return any further values. \keyword{return} with a value, such as ! \code{return 5}, is a syntax error inside a generator function. You ! can also raise \exception{StopIteration} manually, or just let the ! thread of execution fall off the bottom of the function, to achieve ! the same effect. You could achieve the effect of generators manually by writing your ! own class, and storing all the local variables of the generator as instance variables. For example, returning a list of integers could be done by setting \code{self.count} to 0, and having the --- 248,261 ---- Inside a generator function, the \keyword{return} statement can only ! be used without a value, and signals the end of the procession of ! values; afterwards the generator cannot return any further values. ! \keyword{return} with a value, such as \code{return 5}, is a syntax ! error inside a generator function. The end of the generator's results ! can also be indicated by raising \exception{StopIteration} manually, ! or by just letting the flow of execution fall off the bottom of the ! function. You could achieve the effect of generators manually by writing your ! own class and storing all the local variables of the generator as instance variables. For example, returning a list of integers could be done by setting \code{self.count} to 0, and having the *************** *** 309,315 **** \begin{seealso} ! \seepep{255}{Simple Generators}{Written by Neil Schemenauer, ! Tim Peters, Magnus Lie Hetland. Implemented mostly by Neil ! Schemenauer, with fixes from the Python Labs crew.} \end{seealso} --- 316,322 ---- \begin{seealso} ! \seepep{255}{Simple Generators}{Written by Neil Schemenauer, Tim ! Peters, Magnus Lie Hetland. Implemented mostly by Neil Schemenauer ! and Tim Peters, with other fixes from the Python Labs crew.} \end{seealso} *************** *** 517,533 **** \item Various bugfixes and performance improvements have been made ! to the SRE engine underlying the \module{re} module. For example, ! \function{re.sub()} will now use \function{string.replace()} ! automatically when the pattern and its replacement are both just ! literal strings without regex metacharacters. Another contributed ! patch speeds up certain Unicode character ranges by a factor of ! two. (SRE is maintained by Fredrik Lundh. The BIGCHARSET patch ! was contributed by Martin von L\"owis.) \item The \module{imaplib} module now has support for the IMAP ! NAMESPACE extension defined in \rfc{2342}. (Contributed by Michel ! Pelletier.) ! \end{itemize} --- 524,544 ---- \item Various bugfixes and performance improvements have been made ! to the SRE engine underlying the \module{re} module. For example, ! \function{re.sub()} will now use \function{string.replace()} ! automatically when the pattern and its replacement are both just ! literal strings without regex metacharacters. Another contributed ! patch speeds up certain Unicode character ranges by a factor of ! two. (SRE is maintained by Fredrik Lundh. The BIGCHARSET patch was ! contributed by Martin von L\"owis.) \item The \module{imaplib} module now has support for the IMAP ! NAMESPACE extension defined in \rfc{2342}. (Contributed by Michel ! Pelletier.) ! \item The \module{rfc822} module's parsing of e-mail addresses is ! now compliant with \rfc{2822}, an update to \rfc{822}. The module's ! name is \emph{not} going to be changed to \samp{rfc2822}. ! (Contributed by Barry Warsaw.) ! \end{itemize} *************** *** 556,588 **** again. The license changes were also applied to the Python 2.0.1 and 2.1.1 releases. - - \item Profiling and tracing functions can now be implemented in C, - which can operate at much higher speeds than Python-based functions - and should reduce the overhead of enabling profiling and tracing, so - it will be of interest to authors of development environments for - Python. Two new C functions were added to Python's API, - \cfunction{PyEval_SetProfile()} and \cfunction{PyEval_SetTrace()}. - The existing \function{sys.setprofile()} and \function{sys.settrace()} - functions still exist, and have simply been changed to use the new - C-level interface. \item The \file{Tools/scripts/ftpmirror.py} script now parses a \file{.netrc} file, if you have one. ! (Contributed by XXX.) Patch \#430754: Makes ftpmirror.py .netrc aware ! \item Some features of the object returned by the \function{xrange()} ! function are now deprecated, and trigger warnings when they're ! accessed; they'll disappear in Python 2.3. \class{xrange} objects ! tried to pretend they were full sequence types by supporting slicing, ! sequence multiplication, and the \keyword{in} operator, but these ! features were rarely used and therefore buggy. (The implementation of ! the \keyword{in} operator had an off-by-one error introduced in Python ! XXX that no one noticed until XXX, XXX years later. The ! \method{tolist()} method and the \member{start}, \member{stop}, and ! \member{step} attributes are also being deprecated. At the C level, ! the fourth argument to the \cfunction{PyRange_New()} function, ! \samp{repeat}, has also been deprecated. \item XXX C API: Reorganization of object calling --- 567,600 ---- again. The license changes were also applied to the Python 2.0.1 and 2.1.1 releases. + \item Profiling and tracing functions can now be implemented in C, + which can operate at much higher speeds than Python-based functions + and should reduce the overhead of enabling profiling and tracing, so + it will be of interest to authors of development environments for + Python. Two new C functions were added to Python's API, + \cfunction{PyEval_SetProfile()} and \cfunction{PyEval_SetTrace()}. + The existing \function{sys.setprofile()} and + \function{sys.settrace()} functions still exist, and have simply + been changed to use the new C-level interface. \item The \file{Tools/scripts/ftpmirror.py} script now parses a \file{.netrc} file, if you have one. ! (Contributed by Mike Romberg.) ! \item Some features of the object returned by the ! \function{xrange()} function are now deprecated, and trigger ! warnings when they're accessed; they'll disappear in Python 2.3. ! \class{xrange} objects tried to pretend they were full sequence ! types by supporting slicing, sequence multiplication, and the ! \keyword{in} operator, but these features were rarely used and ! therefore buggy. The \method{tolist()} method and the ! \member{start}, \member{stop}, and \member{step} attributes are also ! being deprecated. At the C level, the fourth argument to the ! \cfunction{PyRange_New()} function, \samp{repeat}, has also been ! deprecated. + \item On Windows, Python can now be compiled with Borland C thanks + to a number of patches contribued by Stephen Hansen. + \item XXX C API: Reorganization of object calling *************** *** 604,611 **** %PyEval_GetFuncDesc(), PyEval_EvalCodeEx() (formerly get_func_name(), %get_func_desc(), and eval_code2(). - - \item XXX SF patch \#418147 Fixes to allow compiling w/ Borland, from Stephen Hansen. ! \item XXX Add support for Windows using "mbcs" as the default Unicode encoding when dealing with the file system. As discussed on python-dev and in patch 410465. \item XXX Lots of patches to dictionaries; measure performance improvement, if any. --- 616,623 ---- %PyEval_GetFuncDesc(), PyEval_EvalCodeEx() (formerly get_func_name(), %get_func_desc(), and eval_code2(). ! \item XXX Add support for Windows using "mbcs" as the default ! Unicode encoding when dealing with the file system. As discussed on ! python-dev and in patch 410465. \item XXX Lots of patches to dictionaries; measure performance improvement, if any. *************** *** 619,623 **** The author would like to thank the following people for offering ! suggestions on various drafts of this article: No one yet. \end{document} --- 631,635 ---- The author would like to thank the following people for offering ! suggestions on various drafts of this article: Tim Peters, Neil Schemenauer. \end{document} |
From: A.M. K. <aku...@us...> - 2001-07-16 14:35:56
|
Update of /cvsroot/py-howto/pyhowto In directory usw-pr-cvs1:/tmp/cvs-serv6142 Modified Files: python-22.tex Log Message: Use \longprogramopt, as suggested by FLD Index: python-22.tex =================================================================== RCS file: /cvsroot/py-howto/pyhowto/python-22.tex,v retrieving revision 1.7 retrieving revision 1.8 diff -C2 -r1.7 -r1.8 *** python-22.tex 2001/07/16 13:45:31 1.7 --- python-22.tex 2001/07/16 14:35:52 1.8 *************** *** 321,325 **** strings are usually stored as UCS-2, as 16-bit unsigned integers. Python 2.2 can also be compiled to use UCS-4, 32-bit unsigned integers ! by supplying \verb|--enable-unicode=ucs4| to the configure script. XXX explain surrogates? I have to figure out what the changes mean to users. --- 321,325 ---- strings are usually stored as UCS-2, as 16-bit unsigned integers. Python 2.2 can also be compiled to use UCS-4, 32-bit unsigned integers ! by supplying \longprogramopt{enable-unicode=ucs4} to the configure script. XXX explain surrogates? I have to figure out what the changes mean to users. *************** *** 498,502 **** \item The \module{socket} module can be compiled to support IPv6; ! specify the \code|--enable-ipv6| option to Python's configure script. (Contributed by Jun-ichiro ``itojun'' Hagino.) --- 498,502 ---- \item The \module{socket} module can be compiled to support IPv6; ! specify the \longprogramopt{enable-ipv6} option to Python's configure script. (Contributed by Jun-ichiro ``itojun'' Hagino.) |
From: Fred L. D. <fd...@ac...> - 2001-07-16 14:25:21
|
"A.M. Kuchling" <aku...@us...> wrote: > Use \verb for configure switches, because inside \code > multiple dashes are merged to a single hyphen. No; use \longprogramopt{with-unicode=ucs4} -- this handles the dashes correctly and gives more semantic markup. I need to document the ban on \verb -- LaTeX2HTML doesn't always treat it properly, at least in some versions. -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> PythonLabs at Digital Creations |
From: A.M. K. <aku...@us...> - 2001-07-16 13:45:34
|
Update of /cvsroot/py-howto/pyhowto In directory usw-pr-cvs1:/tmp/cvs-serv28776 Modified Files: python-22.tex Log Message: Use \verb for configure switches, because inside \code multiple dashes are merged to a single hyphen. Delete forgotten CVS conflict marker Index: python-22.tex =================================================================== RCS file: /cvsroot/py-howto/pyhowto/python-22.tex,v retrieving revision 1.6 retrieving revision 1.7 diff -C2 -r1.6 -r1.7 *** python-22.tex 2001/07/16 13:39:08 1.6 --- python-22.tex 2001/07/16 13:45:31 1.7 *************** *** 321,325 **** strings are usually stored as UCS-2, as 16-bit unsigned integers. Python 2.2 can also be compiled to use UCS-4, 32-bit unsigned integers ! by supplying \code{--enable-unicode=ucs4} to the configure script. XXX explain surrogates? I have to figure out what the changes mean to users. --- 321,325 ---- strings are usually stored as UCS-2, as 16-bit unsigned integers. Python 2.2 can also be compiled to use UCS-4, 32-bit unsigned integers ! by supplying \verb|--enable-unicode=ucs4| to the configure script. XXX explain surrogates? I have to figure out what the changes mean to users. *************** *** 454,458 **** used in most Python code (and when it is used, it's often a sign of a poor design anyway). - ======= %\end{seealso} --- 454,457 ---- *************** *** 499,503 **** \item The \module{socket} module can be compiled to support IPv6; ! specify the \code{--enable-ipv6} option to Python's configure script. (Contributed by Jun-ichiro ``itojun'' Hagino.) --- 498,502 ---- \item The \module{socket} module can be compiled to support IPv6; ! specify the \code|--enable-ipv6| option to Python's configure script. (Contributed by Jun-ichiro ``itojun'' Hagino.) |
From: A.M. K. <aku...@us...> - 2001-07-16 13:39:13
|
Update of /cvsroot/py-howto/pyhowto In directory usw-pr-cvs1:/tmp/cvs-serv27284 Modified Files: python-22.tex Log Message: Write some entries in the "Other changes" section Write description of .encode()/.decode for the Unicode section Bump version number Index: python-22.tex =================================================================== RCS file: /cvsroot/py-howto/pyhowto/python-22.tex,v retrieving revision 1.5 retrieving revision 1.6 diff -C2 -r1.5 -r1.6 *** python-22.tex 2001/07/16 02:17:14 1.5 --- python-22.tex 2001/07/16 13:39:08 1.6 *************** *** 4,8 **** \title{What's New in Python 2.2} ! \release{0.01} \author{A.M. Kuchling} \authoraddress{\email{aku...@me...}} --- 4,8 ---- \title{What's New in Python 2.2} ! \release{0.02} \author{A.M. Kuchling} \authoraddress{\email{aku...@me...}} *************** *** 318,323 **** \section{Unicode Changes} ! XXX I have to figure out what the changes mean to users. ! (--enable-unicode configure switch) References: http://mail.python.org/pipermail/i18n-sig/2001-June/001107.html --- 318,357 ---- \section{Unicode Changes} ! Python's Unicode support has been enhanced a bit in 2.2. Unicode ! strings are usually stored as UCS-2, as 16-bit unsigned integers. ! Python 2.2 can also be compiled to use UCS-4, 32-bit unsigned integers ! by supplying \code{--enable-unicode=ucs4} to the configure script. ! ! XXX explain surrogates? I have to figure out what the changes mean to users. ! ! Since their introduction, Unicode strings (XXX and regular strings in ! 2.1?) have supported an \method{encode()} method to convert the ! string to a selected encoding such as UTF-8 or Latin-1. A symmetric ! \method{decode(\optional{\var{encoding}})} method has been added to ! both 8-bit and Unicode strings in 2.2, which assumes that the string ! is in the specified encoding and decodes it. This means that ! \method{encode()} and \method{decode()} can be called on both types of ! strings, and can be used for tasks not directly related to Unicode. ! For example, codecs have been added for UUencoding, MIME's base-64 ! encoding, and compression with the \module{zlib} module. ! ! \begin{verbatim} ! >>> s = """Here is a lengthy piece of redundant, overly verbose, ! ... and repetitive text. ! ... """ ! >>> data = s.encode('zlib') ! >>> data ! 'x\x9c\r\xc9\xc1\r\x80 \x10\x04\xc0?Ul...' ! >>> data.decode('zlib') ! 'Here is a lengthy piece of redundant, overly verbose,\nand repetitive text.\n' ! >>> print s.encode('uu') ! begin 666 <data> ! M2&5R92!I<R!A(&QE;F=T:'D@<&EE8V4@;V8@<F5D=6YD86YT+"!O=F5R;'D@ ! >=F5R8F]S92P*86YD(')E<&5T:71I=F4@=&5X="X* ! ! end ! >>> "sheesh".encode('rot-13') ! 'furrfu' ! \end{verbatim} References: http://mail.python.org/pipermail/i18n-sig/2001-June/001107.html *************** *** 510,567 **** \begin{itemize} - - \item XXX C API: Reorganization of object calling - - \item XXX .encode(), .decode() string methods. Interesting new codecs such - as zlib. - - \item MacOS code now in main CVS tree. - - \item SF patch \#418147 Fixes to allow compiling w/ Borland, from Stephen Hansen. - - \item Add support for Windows using "mbcs" as the default Unicode encoding when dealing with the file system. As discussed on python-dev and in patch 410465. - - \item Lots of patches to dictionaries; measure performance improvement, if any. - - \item Patch \#430754: Makes ftpmirror.py .netrc aware - - \item Fix bug reported by Tim Peters on python-dev: ! Keyword arguments passed to builtin functions that don't take them are ! ignored. ! >>> {}.clear(x=2) ! >>> ! ! instead of ! ! >>> {}.clear(x=2) ! Traceback (most recent call last): ! File "<stdin>", line 1, in ? ! TypeError: clear() takes no keyword arguments ! \item Make the license GPL-compatible. - \item This change adds two new C-level APIs: PyEval_SetProfile() and - PyEval_SetTrace(). These can be used to install profile and trace - functions implemented in C, which can operate at much higher speeds - than Python-based functions. The overhead for calling a C-based - profile function is a very small fraction of a percent of the overhead - involved in calling a Python-based function. - - The machinery required to call a Python-based profile or trace - function been moved to sysmodule.c, where sys.setprofile() and - sys.setprofile() simply become users of the new interface. - - \item 'Advanced' xrange() features now deprecated: repeat, slice, - contains, tolist(), and the start/stop/step attributes. This includes - removing the 4th ('repeat') argument to PyRange_New(). - - - \item The call_object() function, originally in ceval.c, begins a new life - %as the official API PyObject_Call(). It is also much simplified: all - %it does is call the tp_call slot, or raise an exception if that's - %NULL. - %The subsidiary functions (call_eval_code2(), call_cfunction(), %call_instance(), and call_method()) have all been moved to the file --- 544,596 ---- \begin{itemize} ! \item Keyword arguments passed to builtin functions that don't take them ! now cause a \exception{TypeError} exception to be raised, with the ! message "\var{function} takes no keyword arguments". ! ! \item The code for the MacOS port for Python, maintained by Jack ! Jansen, is now kept in the main Python CVS tree. ! ! \item The new license introduced with Python 1.6 wasn't ! GPL-compatible. This is fixed by some minor textual changes to the ! 2.2 license, so Python can now be embedded inside a GPLed program ! again. The license changes were also applied to the Python 2.0.1 ! and 2.1.1 releases. ! ! \item Profiling and tracing functions can now be implemented in C, ! which can operate at much higher speeds than Python-based functions ! and should reduce the overhead of enabling profiling and tracing, so ! it will be of interest to authors of development environments for ! Python. Two new C functions were added to Python's API, ! \cfunction{PyEval_SetProfile()} and \cfunction{PyEval_SetTrace()}. ! The existing \function{sys.setprofile()} and \function{sys.settrace()} ! functions still exist, and have simply been changed to use the new ! C-level interface. ! ! ! \item The \file{Tools/scripts/ftpmirror.py} script ! now parses a \file{.netrc} file, if you have one. ! (Contributed by XXX.) Patch \#430754: Makes ftpmirror.py .netrc aware ! ! \item Some features of the object returned by the \function{xrange()} ! function are now deprecated, and trigger warnings when they're ! accessed; they'll disappear in Python 2.3. \class{xrange} objects ! tried to pretend they were full sequence types by supporting slicing, ! sequence multiplication, and the \keyword{in} operator, but these ! features were rarely used and therefore buggy. (The implementation of ! the \keyword{in} operator had an off-by-one error introduced in Python ! XXX that no one noticed until XXX, XXX years later. The ! \method{tolist()} method and the \member{start}, \member{stop}, and ! \member{step} attributes are also being deprecated. At the C level, ! the fourth argument to the \cfunction{PyRange_New()} function, ! \samp{repeat}, has also been deprecated. ! \item XXX C API: Reorganization of object calling ! The call_object() ! function, originally in ceval.c, begins a new life as the official ! API PyObject_Call(). It is also much simplified: all it does is call ! the tp_call slot, or raise an exception if that's NULL. %The subsidiary functions (call_eval_code2(), call_cfunction(), %call_instance(), and call_method()) have all been moved to the file *************** *** 576,579 **** --- 605,614 ---- %PyEval_GetFuncDesc(), PyEval_EvalCodeEx() (formerly get_func_name(), %get_func_desc(), and eval_code2(). + + \item XXX SF patch \#418147 Fixes to allow compiling w/ Borland, from Stephen Hansen. + + \item XXX Add support for Windows using "mbcs" as the default Unicode encoding when dealing with the file system. As discussed on python-dev and in patch 410465. + + \item XXX Lots of patches to dictionaries; measure performance improvement, if any. \end{itemize} |
From: A.M. K. <aku...@us...> - 2001-07-16 02:17:17
|
Update of /cvsroot/py-howto/pyhowto In directory usw-pr-cvs1:/tmp/cvs-serv28850 Modified Files: python-22.tex Log Message: Began actually writing: * iterators * generators * copied the nested scopes section from the 2.1 article * standard library changes Index: python-22.tex =================================================================== RCS file: /cvsroot/py-howto/pyhowto/python-22.tex,v retrieving revision 1.4 retrieving revision 1.5 diff -C2 -r1.4 -r1.5 *** python-22.tex 2001/07/11 18:54:26 1.4 --- python-22.tex 2001/07/16 02:17:14 1.5 *************** *** 30,36 **** %====================================================================== \section{PEP 234: Iterators} ! XXX \begin{seealso} --- 30,170 ---- %====================================================================== + % It looks like this set of changes will likely get into 2.2, + % so I need to read and digest the relevant PEPs. + %\section{PEP 252: Type and Class Changes} + + %XXX + + %\begin{seealso} + + %\seepep{252}{Making Types Look More Like Classes}{Written and implemented + %by GvR.} + + %\end{seealso} + + %====================================================================== \section{PEP 234: Iterators} ! A significant addition to 2.2 is an iteration interface at both the C ! and Python levels. Objects can define how they can be looped over by ! callers. ! ! In Python versions up to 2.1, the usual way to make \code{for item in ! obj} work is to define a \method{__getitem__()} method that looks ! something like this: ! ! \begin{verbatim} ! def __getitem__(self, index): ! return <next item> ! \end{verbatim} ! ! \method{__getitem__()} is more properly used to define an indexing ! operation on an object so that you can write \code{obj[5]} to retrieve ! the fifth element. It's a bit misleading when you're using this only ! to support \keyword{for} loops. Consider some file-like object that ! wants to be looped over; the \var{index} parameter is essentially ! meaningless, as the class probably assumes that a series of ! \method{__getitem__()} calls will be made, with \var{index} ! incrementing by one each time. In other words, the presence of the ! \method{__getitem__()} method doesn't mean that \code{file[5]} will ! work, though it really should. ! ! In Python 2.2, iteration can be implemented separately, and ! \method{__getitem__()} methods can be limited to classes that really ! do support random access. The basic idea of iterators is quite ! simple. A new built-in function, \function{iter(obj)}, returns an ! iterator for the object \var{obj}. (It can also take two arguments: ! \code{iter(\var{C}, \var{sentinel})} will call the callable \var{C}, until it ! returns \var{sentinel}, which will signal that the iterator is done. This form probably won't be used very often.) ! ! Python classes can define an \method{__iter__()} method, which should ! create and return a new iterator for the object; if the object is its ! own iterator, this method can just return \code{self}. In particular, ! iterators will usually be their own iterators. Extension types ! implemented in C can implement a \code{tp_iter} function in order to ! return an iterator, too. ! ! So what do iterators do? They have one required method, ! \method{next()}, which takes no arguments and returns the next value. ! When there are no more values to be returned, calling \method{next()} ! should raise the \exception{StopIteration} exception. ! ! \begin{verbatim} ! >>> L = [1,2,3] ! >>> i = iter(L) ! >>> print i ! <iterator object at 0x8116870> ! >>> i.next() ! 1 ! >>> i.next() ! 2 ! >>> i.next() ! 3 ! >>> i.next() ! Traceback (most recent call last): ! File "<stdin>", line 1, in ? ! StopIteration ! >>> ! \end{verbatim} ! ! In 2.2, Python's \keyword{for} statement no longer expects a sequence; ! it expects something for which \function{iter()} will return something. ! For backward compatibility, and convenience, an iterator is ! automatically constructed for sequences that don't implement ! \method{__iter__()} or a \code{tp_iter} slot, so \code{for i in ! [1,2,3]} will still work. Wherever the Python interpreter loops over ! a sequence, it's been changed to use the iterator protocol. This ! means you can do things like this: ! ! \begin{verbatim} ! >>> i = iter(L) ! >>> a,b,c = i ! >>> a,b,c ! (1, 2, 3) ! >>> ! \end{verbatim} ! ! Iterator support has been added to some of Python's basic types. The ! \keyword{in} operator now works on dictionaries, so \code{\var{key} in ! dict} is now equivalent to \code{dict.has_key(\var{key})}. ! Calling \function{iter()} on a dictionary will return an iterator which loops over their keys: ! ! \begin{verbatim} ! >>> m = {'Jan': 1, 'Feb': 2, 'Mar': 3, 'Apr': 4, 'May': 5, 'Jun': 6, ! ... 'Jul': 7, 'Aug': 8, 'Sep': 9, 'Oct': 10, 'Nov': 11, 'Dec': 12} ! >>> for key in m: print key, m[key] ! ... ! Mar 3 ! Feb 2 ! Aug 8 ! Sep 9 ! May 5 ! Jun 6 ! Jul 7 ! Jan 1 ! Apr 4 ! Nov 11 ! Dec 12 ! Oct 10 ! >>> ! \end{verbatim} ! ! That's just the default behaviour. If you want to iterate over keys, ! values, or key/value pairs, you can explicitly call the ! \method{iterkeys()}, \method{itervalues()}, or \method{iteritems()} ! methods to get an appropriate iterator. ! ! Files also provide an iterator, which calls its \method{readline()} ! method until there are no more lines in the file. This means you can ! now read each line of a file using code like this: ! ! \begin{verbatim} ! for line in file: ! # do something for each line ! \end{verbatim} ! ! Note that you can only go forward in an iterator; there's no way to ! get the previous element, reset the iterator, or make a copy of it. ! An iterator object could provide such additional capabilities, but the iterator protocol only requires a \method{next()} method. \begin{seealso} *************** *** 43,48 **** %====================================================================== \section{PEP 255: Simple Generators} ! XXX \begin{seealso} --- 177,309 ---- %====================================================================== \section{PEP 255: Simple Generators} + + Generators are another new feature, one that interacts with the + introduction of iterators. ! You're doubtless familiar with how function calls work in Python or ! C. When you call a function, it gets a private area where its local ! variables are created. When the function reaches a \keyword{return} ! statement, the local variables are destroyed and the resulting value ! is returned to the caller. A later call to the same function will get ! a fresh new set of local variables. But, what if the local variables ! weren't destroyed on exiting a function? What if you could later ! resume the function where it left off? This is what generators ! provide; they can be thought of as resumable functions. ! ! Here's the simplest example of a generator function: ! ! \begin{verbatim} ! def generate_ints(N): ! for i in range(N): ! yield i ! \end{verbatim} ! ! A new keyword, \keyword{yield}, was introduced for generators. Any ! function containing a \keyword{yield} statement is a generator ! function; this is detected by Python's bytecode compiler which ! compiles the function specially. When you call a generator function, ! it doesn't return a single value; instead it returns a generator ! object that supports the iterator interface. On executing the ! \keyword{yield} statement, the generator outputs the value of ! \code{i}, similar to a \keyword{return} statement. The big difference ! between \keyword{yield} and a \keyword{return} statement is that, on ! reaching a \keyword{yield} the generator's state of execution is ! suspended and local variables are preserved. On the next call to the ! generator's \code{.next()} method, the function will resume executing ! immediately after the \keyword{yield} statement. (For complicated ! reasons, the \keyword{yield} statement isn't allowed inside the ! \keyword{try} block of a \code{try...finally} statement; read PEP 255 ! for a full explanation of the interaction between \keyword{yield} and ! exceptions.) ! ! Here's a sample usage of the \function{generate_ints} generator: ! ! \begin{verbatim} ! >>> gen = generate_ints(3) ! >>> gen ! <generator object at 0x8117f90> ! >>> gen.next() ! 0 ! >>> gen.next() ! 1 ! >>> gen.next() ! 2 ! >>> gen.next() ! Traceback (most recent call last): ! File "<stdin>", line 1, in ? ! File "<stdin>", line 2, in generate_ints ! StopIteration ! >>> ! \end{verbatim} ! ! You could equally write \code{for i in generate_ints(5)}, or ! \code{a,b,c = generate_ints(3)}. ! ! Inside a generator function, the \keyword{return} statement can only ! be used without a value, and is equivalent to raising the ! \exception{StopIteration} exception; afterwards the generator cannot ! return any further values. \keyword{return} with a value, such as ! \code{return 5}, is a syntax error inside a generator function. You ! can also raise \exception{StopIteration} manually, or just let the ! thread of execution fall off the bottom of the function, to achieve ! the same effect. ! ! You could achieve the effect of generators manually by writing your ! own class, and storing all the local variables of the generator as ! instance variables. For example, returning a list of integers could ! be done by setting \code{self.count} to 0, and having the ! \method{next()} method increment \code{self.count} and return it. ! because it would be easy to write a Python class. However, for a ! moderately complicated generator, writing a corresponding class would ! be much messier. \file{Lib/test/test_generators.py} contains a number ! of more interesting examples. The simplest one implements an in-order ! traversal of a tree using generators recursively. ! ! \begin{verbatim} ! # A recursive generator that generates Tree leaves in in-order. ! def inorder(t): ! if t: ! for x in inorder(t.left): ! yield x ! yield t.label ! for x in inorder(t.right): ! yield x ! \end{verbatim} ! ! Two other examples in \file{Lib/test/test_generators.py} produce ! solutions for the N-Queens problem (placing $N$ queens on an $NxN$ ! chess board so that no queen threatens another) and the Knight's Tour ! (a route that takes a knight to every square of an $NxN$ chessboard ! without visiting any square twice). ! ! The idea of generators comes from other programming languages, ! especially Icon (\url{http://www.cs.arizona.edu/icon/}), where the ! idea of generators is central to the language. In Icon, every ! expression and function call behaves like a generator. One example ! from ``An Overview of the Icon Programming Language'' at ! \url{http://www.cs.arizona.edu/icon/docs/ipd266.htm} gives an idea of ! what this looks like: ! ! \begin{verbatim} ! sentence := "Store it in the neighboring harbor" ! if (i := find("or", sentence)) > 5 then write(i) ! \end{verbatim} ! ! The \function{find()} function returns the indexes at which the ! substring ``or'' is found: 3, 23, 33. In the \keyword{if} statement, ! \code{i} is first assigned a value of 3, but 3 is less than 5, so the ! comparison fails, and Icon retries it with the second value of 23. 23 ! is greater than 5, so the comparison now succeeds, and the code prints ! the value 23 to the screen. ! ! Python doesn't go nearly as far as Icon in adopting generators as a ! central concept. Generators are considered a new part of the core ! Python language, but learning or using them isn't compulsory; if they ! don't solve any problems that you have, feel free to ignore them. ! This is different from Icon where the idea of generators is a basic ! concept. One novel feature of Python's interface as compared to ! Icon's is that a generator's state is represented as a concrete object ! that can be passed around to other functions or stored in a data ! structure. \begin{seealso} *************** *** 50,81 **** \seepep{255}{Simple Generators}{Written by Neil Schemenauer, Tim Peters, Magnus Lie Hetland. Implemented mostly by Neil ! Schemenauer, with fixes from the Python Labs crew, mostly by GvR and ! Tim Peters.} \end{seealso} %====================================================================== ! % It looks like this set of changes isn't going to be getting into 2.2, ! % unless someone plans to merge the descr-branch back into the mainstream ! % very quickly. ! %\section{PEP 252: Type and Class Changes} ! %XXX ! %\begin{seealso} ! %\seepep{252}{Making Types Look More Like Classes}{Written and implemented ! %by GvR.} %\end{seealso} ! %====================================================================== ! \section{Unicode Changes} ! XXX I have to figure out what the changes mean to users. ! (--enable-unicode configure switch) ! References: http://mail.python.org/pipermail/i18n-sig/2001-June/001107.html ! and following thread. --- 311,432 ---- \seepep{255}{Simple Generators}{Written by Neil Schemenauer, Tim Peters, Magnus Lie Hetland. Implemented mostly by Neil ! Schemenauer, with fixes from the Python Labs crew.} \end{seealso} %====================================================================== ! \section{Unicode Changes} ! XXX I have to figure out what the changes mean to users. ! (--enable-unicode configure switch) ! References: http://mail.python.org/pipermail/i18n-sig/2001-June/001107.html ! and following thread. ! %====================================================================== ! \section{PEP 227: Nested Scopes} + In Python 2.1, statically nested scopes were added as an optional + feature, to be enabled by a \code{from __future__ import + nested_scopes} directive. In 2.2 nested scopes no longer need to be + specially enabled, but are always enabled. The rest of this section + is a copy of the description of nested scopes from my ``What's New in + Python 2.1'' document; if you read it when 2.1 came out, you can skip + the rest of this section. + + The largest change introduced in Python 2.1, and made complete in 2.2, + is to Python's scoping rules. In Python 2.0, at any given time there + are at most three namespaces used to look up variable names: local, + module-level, and the built-in namespace. This often surprised people + because it didn't match their intuitive expectations. For example, a + nested recursive function definition doesn't work: + + \begin{verbatim} + def f(): + ... + def g(value): + ... + return g(value-1) + 1 + ... + \end{verbatim} + + The function \function{g()} will always raise a \exception{NameError} + exception, because the binding of the name \samp{g} isn't in either + its local namespace or in the module-level namespace. This isn't much + of a problem in practice (how often do you recursively define interior + functions like this?), but this also made using the \keyword{lambda} + statement clumsier, and this was a problem in practice. In code which + uses \keyword{lambda} you can often find local variables being copied + by passing them as the default values of arguments. + + \begin{verbatim} + def find(self, name): + "Return list of any entries equal to 'name'" + L = filter(lambda x, name=name: x == name, + self.list_attribute) + return L + \end{verbatim} + + The readability of Python code written in a strongly functional style + suffers greatly as a result. + + The most significant change to Python 2.2 is that static scoping has + been added to the language to fix this problem. As a first effect, + the \code{name=name} default argument is now unnecessary in the above + example. Put simply, when a given variable name is not assigned a + value within a function (by an assignment, or the \keyword{def}, + \keyword{class}, or \keyword{import} statements), references to the + variable will be looked up in the local namespace of the enclosing + scope. A more detailed explanation of the rules, and a dissection of + the implementation, can be found in the PEP. + + This change may cause some compatibility problems for code where the + same variable name is used both at the module level and as a local + variable within a function that contains further function definitions. + This seems rather unlikely though, since such code would have been + pretty confusing to read in the first place. + + One side effect of the change is that the \code{from \var{module} + import *} and \keyword{exec} statements have been made illegal inside + a function scope under certain conditions. The Python reference + manual has said all along that \code{from \var{module} import *} is + only legal at the top level of a module, but the CPython interpreter + has never enforced this before. As part of the implementation of + nested scopes, the compiler which turns Python source into bytecodes + has to generate different code to access variables in a containing + scope. \code{from \var{module} import *} and \keyword{exec} make it + impossible for the compiler to figure this out, because they add names + to the local namespace that are unknowable at compile time. + Therefore, if a function contains function definitions or + \keyword{lambda} expressions with free variables, the compiler will + flag this by raising a \exception{SyntaxError} exception. + + To make the preceding explanation a bit clearer, here's an example: + + \begin{verbatim} + x = 1 + def f(): + # The next line is a syntax error + exec 'x=2' + def g(): + return x + \end{verbatim} + + Line 4 containing the \keyword{exec} statement is a syntax error, + since \keyword{exec} would define a new local variable named \samp{x} + whose value should be accessed by \function{g()}. + + This shouldn't be much of a limitation, since \keyword{exec} is rarely + used in most Python code (and when it is used, it's often a sign of a + poor design anyway). + ======= %\end{seealso} ! \begin{seealso} ! \seepep{227}{Statically Nested Scopes}{Written and implemented by ! Jeremy Hylton.} ! \end{seealso} *************** *** 84,89 **** \begin{itemize} - \item xmlrpclib added to standard library. \end{itemize} --- 435,499 ---- \begin{itemize} + + \item The \module{xmlrpclib} module was contributed to the standard + library by Fredrik Lundh. It provides support for writing XML-RPC + clients; XML-RPC is a simple remote procedure call protocol built on + top of HTTP and XML. For example, the following snippet retrieves a + list of RSS channels from the O'Reilly Network, and then retrieves a + list of the recent headlines for one channel: + + \begin{verbatim} + import xmlrpclib + s = xmlrpclib.Server( + 'http://www.oreillynet.com/meerkat/xml-rpc/server.php') + channels = s.meerkat.getChannels() + # channels is a list of dictionaries, like this: + # [{'id': 4, 'title': 'Freshmeat Daily News'} + # {'id': 190, 'title': '32Bits Online'}, + # {'id': 4549, 'title': '3DGamers'}, ... ] + + # Get the items for one channel + items = s.meerkat.getItems( {'channel': 4} ) + + # 'items' is another list of dictionaries, like this: + # [{'link': 'http://freshmeat.net/releases/52719/', + # 'description': 'A utility which converts HTML to XSL FO.', + # 'title': 'html2fo 0.3 (Default)'}, ... ] + \end{verbatim} + + See \url{http://www.xmlrpc.com} for more information about XML-RPC. + + \item The \module{socket} module can be compiled to support IPv6; + specify the \code{--enable-ipv6} option to Python's configure + script. (Contributed by Jun-ichiro ``itojun'' Hagino.) + + \item Two new format characters were added to the \module{struct} + module for 64-bit integers on platforms that support the C + \ctype{long long} type. \samp{q} is for a signed 64-bit integer, + and \samp{Q} is for an unsigned one. The value is returned in + Python's long integer type. (Contributed by Tim Peters.) + + \item In the interpreter's interactive mode, there's a new built-in + function \function{help()}, that uses the \module{pydoc} module + introduced in Python 2.1 to provide interactive. + \code{help(\var{object})} displays any available help text about + \var{object}. \code{help()} with no argument puts you in an online + help utility, where you can enter the names of functions, classes, + or modules to read their help text. + (Contributed by Guido van Rossum, using Ka-Ping Yee's \module{pydoc} module.) + + \item Various bugfixes and performance improvements have been made + to the SRE engine underlying the \module{re} module. For example, + \function{re.sub()} will now use \function{string.replace()} + automatically when the pattern and its replacement are both just + literal strings without regex metacharacters. Another contributed + patch speeds up certain Unicode character ranges by a factor of + two. (SRE is maintained by Fredrik Lundh. The BIGCHARSET patch + was contributed by Martin von L\"owis.) + + \item The \module{imaplib} module now has support for the IMAP + NAMESPACE extension defined in \rfc{2342}. (Contributed by Michel + Pelletier.) \end{itemize} *************** *** 93,110 **** \section{Other Changes and Fixes} ! XXX \begin{itemize} - \item XXX Nested scoping enabled by default - \item XXX C API: Reorganization of object calling \item XXX .encode(), .decode() string methods. Interesting new codecs such ! as zlib. ! %Original log message: ! ! %The call_object() function, originally in ceval.c, begins a new life %as the official API PyObject_Call(). It is also much simplified: all %it does is call the tp_call slot, or raise an exception if that's --- 503,563 ---- \section{Other Changes and Fixes} ! As usual there were a bunch of other improvements and bugfixes ! scattered throughout the source tree. A search through the CVS change ! logs finds there were XXX patches applied, and XXX bugs fixed; both ! figures are likely to be underestimates. Some of the more notable ! changes are: \begin{itemize} \item XXX C API: Reorganization of object calling \item XXX .encode(), .decode() string methods. Interesting new codecs such ! as zlib. ! ! \item MacOS code now in main CVS tree. ! ! \item SF patch \#418147 Fixes to allow compiling w/ Borland, from Stephen Hansen. ! ! \item Add support for Windows using "mbcs" as the default Unicode encoding when dealing with the file system. As discussed on python-dev and in patch 410465. ! ! \item Lots of patches to dictionaries; measure performance improvement, if any. ! ! \item Patch \#430754: Makes ftpmirror.py .netrc aware ! ! \item Fix bug reported by Tim Peters on python-dev: ! ! Keyword arguments passed to builtin functions that don't take them are ! ignored. ! ! >>> {}.clear(x=2) ! >>> ! ! instead of ! ! >>> {}.clear(x=2) ! Traceback (most recent call last): ! File "<stdin>", line 1, in ? ! TypeError: clear() takes no keyword arguments ! ! \item Make the license GPL-compatible. ! ! \item This change adds two new C-level APIs: PyEval_SetProfile() and ! PyEval_SetTrace(). These can be used to install profile and trace ! functions implemented in C, which can operate at much higher speeds ! than Python-based functions. The overhead for calling a C-based ! profile function is a very small fraction of a percent of the overhead ! involved in calling a Python-based function. ! ! The machinery required to call a Python-based profile or trace ! function been moved to sysmodule.c, where sys.setprofile() and ! sys.setprofile() simply become users of the new interface. ! ! \item 'Advanced' xrange() features now deprecated: repeat, slice, ! contains, tolist(), and the start/stop/step attributes. This includes ! removing the 4th ('repeat') argument to PyRange_New(). ! ! \item The call_object() function, originally in ceval.c, begins a new life %as the official API PyObject_Call(). It is also much simplified: all %it does is call the tp_call slot, or raise an exception if that's |
From: A.M. K. <aku...@us...> - 2001-07-16 01:26:10
|
Update of /cvsroot/py-howto/pyhowto In directory usw-pr-cvs1:/tmp/cvs-serv14932 Modified Files: python-dev.tex Log Message: Add forgotten http:// prefix to URL Index: python-dev.tex =================================================================== RCS file: /cvsroot/py-howto/pyhowto/python-dev.tex,v retrieving revision 1.8 retrieving revision 1.9 diff -C2 -r1.8 -r1.9 *** python-dev.tex 2001/07/10 17:31:53 1.8 --- python-dev.tex 2001/07/16 01:26:07 1.9 *************** *** 357,361 **** The most general and most high-traffic list is \email{python-list} ! (\url{mail.python.org/mailman/listinfo/python-list}), which is gatewayed to the Usenet newsgroup \newsgroup{comp.lang.python}. Pretty much anything Python-related is fair game for discussion, and --- 357,361 ---- The most general and most high-traffic list is \email{python-list} ! (\url{http://mail.python.org/mailman/listinfo/python-list}), which is gatewayed to the Usenet newsgroup \newsgroup{comp.lang.python}. Pretty much anything Python-related is fair game for discussion, and |
From: Eric S. R. <es...@th...> - 2001-07-11 22:27:30
|
Andrew Kuchling <aku...@me...>: > On Wed, Jul 11, 2001 at 03:05:22PM -0400, Eric S. Raymond wrote: > >Does this mean xmlrpclib has been checked in? Should I start working on > >documentation? > > Yes. Don't have access to your python-checkins mail at the moment? > /F checked it in a few hours ago, so you can probably start working on > docs. Might want to check if /F has some already, though. He doesn't and I am. I'm writing the section on type marshalling now. -- <a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a> It will be of little avail to the people, that the laws are made by men of their own choice, if the laws be so voluminous that they cannot be read, or so incoherent that they cannot be understood; if they be repealed or revised before they are promulgated, or undergo such incessant changes that no man, who knows what the law is to-day, can guess what it will be to-morrow. Law is defined to be a rule of action; but how can that be a rule, which is little known, and less fixed? -- James Madison, Federalist Papers 62 |
From: Fred L. D. Jr. <fd...@ac...> - 2001-07-11 19:41:45
|
Eric S. Raymond writes: > Does this mean xmlrpclib has been checked in? Should I start working on > documentation? Yes, and please! Just check in Doc/lib/libxmlrpmlib.tex whenever you're ready, and I'll cross the i's and dot the t's. -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> PythonLabs at Digital Creations |
From: Andrew K. <aku...@me...> - 2001-07-11 19:07:59
|
On Wed, Jul 11, 2001 at 03:05:22PM -0400, Eric S. Raymond wrote: >Does this mean xmlrpclib has been checked in? Should I start working on >documentation? Yes. Don't have access to your python-checkins mail at the moment? /F checked it in a few hours ago, so you can probably start working on docs. Might want to check if /F has some already, though. --amk |
From: Eric S. R. <es...@th...> - 2001-07-11 19:00:45
|
A.M. Kuchling <aku...@us...>: > *************** > *** 82,86 **** > \begin{itemize} > > ! \item XXX > > \end{itemize} > --- 85,89 ---- > \begin{itemize} > > ! \item xmlrpclib added to standard library. > > \end{itemize} Does this mean xmlrpclib has been checked in? Should I start working on documentation? -- <a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a> No matter how one approaches the figures, one is forced to the rather startling conclusion that the use of firearms in crime was very much less when there were no controls of any sort and when anyone, convicted criminal or lunatic, could buy any type of firearm without restriction. Half a century of strict controls on pistols has ended, perversely, with a far greater use of this weapon in crime than ever before. -- Colin Greenwood, in the study "Firearms Control", 1972 |
From: A.M. K. <aku...@us...> - 2001-07-11 18:54:29
|
Update of /cvsroot/py-howto/pyhowto In directory usw-pr-cvs1:/tmp/cvs-serv25953 Modified Files: python-22.tex Log Message: Note addition of xmlrpclib Comment out descr-branch section Update e-mail address (Time to begin writing this...) Index: python-22.tex =================================================================== RCS file: /cvsroot/py-howto/pyhowto/python-22.tex,v retrieving revision 1.3 retrieving revision 1.4 diff -C2 -r1.3 -r1.4 *** python-22.tex 2001/06/27 20:32:12 1.3 --- python-22.tex 2001/07/11 18:54:26 1.4 *************** *** 6,10 **** \release{0.01} \author{A.M. Kuchling} ! \authoraddress{\email{am...@bi...}} \begin{document} \maketitle\tableofcontents --- 6,10 ---- \release{0.01} \author{A.M. Kuchling} ! \authoraddress{\email{aku...@me...}} \begin{document} \maketitle\tableofcontents *************** *** 15,23 **** final version of Python 2.2 is released. Currently it's not up to date at all. Please send any comments, bug reports, or questions, no ! matter how minor, to \email{am...@bi...}. } ! This article explains the new features in Python 2.2. ! Python 2.2 includes some significant changes that go far toward cleaning up ! the language's darkest corners. This article doesn't attempt to provide a complete specification for --- 15,23 ---- final version of Python 2.2 is released. Currently it's not up to date at all. Please send any comments, bug reports, or questions, no ! matter how minor, to \email{aku...@me...}. } ! This article explains the new features in Python 2.2. Python 2.2 ! includes some significant changes that go far toward cleaning up the ! language's darkest corners, and some exciting new features. This article doesn't attempt to provide a complete specification for *************** *** 56,69 **** %====================================================================== ! \section{PEP 252: Type and Class Changes} ! XXX ! \begin{seealso} ! \seepep{252}{Making Types Look More Like Classes}{Written and implemented ! by GvR.} ! \end{seealso} %====================================================================== --- 56,72 ---- %====================================================================== ! % It looks like this set of changes isn't going to be getting into 2.2, ! % unless someone plans to merge the descr-branch back into the mainstream ! % very quickly. ! %\section{PEP 252: Type and Class Changes} ! %XXX ! %\begin{seealso} ! %\seepep{252}{Making Types Look More Like Classes}{Written and implemented ! %by GvR.} ! %\end{seealso} %====================================================================== *************** *** 82,86 **** \begin{itemize} ! \item XXX \end{itemize} --- 85,89 ---- \begin{itemize} ! \item xmlrpclib added to standard library. \end{itemize} |
From: A.M. K. <aku...@us...> - 2001-07-10 17:31:57
|
Update of /cvsroot/py-howto/pyhowto In directory usw-pr-cvs1:/tmp/cvs-serv26611 Modified Files: python-dev.tex Log Message: Amusing braino noticed by Steve Ferg Index: python-dev.tex =================================================================== RCS file: /cvsroot/py-howto/pyhowto/python-dev.tex,v retrieving revision 1.7 retrieving revision 1.8 diff -C2 -r1.7 -r1.8 *** python-dev.tex 2001/07/10 01:03:05 1.7 --- python-dev.tex 2001/07/10 17:31:53 1.8 *************** *** 416,424 **** difficult to start a new SIG, and the maintainers of \url{http://www.python.org} will want some fairly clear evidence that the new ! SIG will attack enough interest (and developers) to achieve its goal. You might be happiest just creating a mailing list to discuss your topic, whether on a server you own or on Yahoo Groups ! (\url{http://groups.yahoo.com}) or some other free list service, rather than ! bother with the formalities of creating a SIG. \subsection{python-dev} --- 416,424 ---- difficult to start a new SIG, and the maintainers of \url{http://www.python.org} will want some fairly clear evidence that the new ! SIG will attract enough interest (and developers) to achieve its goal. You might be happiest just creating a mailing list to discuss your topic, whether on a server you own or on Yahoo Groups ! (\url{http://groups.yahoo.com}) or some other free list service, ! rather than bother with the formalities of creating a SIG. \subsection{python-dev} *************** *** 476,481 **** The author would like to thank the following people for offering ! suggestions on various drafts of this article: Aahz Maruch, Skip ! Montanaro, Guido van Rossum. \end{document} --- 476,481 ---- The author would like to thank the following people for offering ! suggestions on various drafts of this article: Steve Ferg, Aahz ! Maruch, Skip Montanaro, Guido van Rossum. \end{document} |