Andrew M. Kuchling | 90cecee | 2001-01-22 04:02:09 +0000 | [diff] [blame] | 1 | \documentclass{howto} |
| 2 | |
| 3 | % $Id$ |
| 4 | |
| 5 | \title{What's New in Python 2.1} |
Andrew M. Kuchling | 81b6ae7 | 2001-02-11 16:55:39 +0000 | [diff] [blame] | 6 | \release{0.06} |
Andrew M. Kuchling | 90cecee | 2001-01-22 04:02:09 +0000 | [diff] [blame] | 7 | \author{A.M. Kuchling} |
| 8 | \authoraddress{\email{amk1@bigfoot.com}} |
| 9 | \begin{document} |
| 10 | \maketitle\tableofcontents |
| 11 | |
| 12 | \section{Introduction} |
| 13 | |
Andrew M. Kuchling | f33c118 | 2001-01-23 02:48:26 +0000 | [diff] [blame] | 14 | {\large This document is a draft, and is subject to change until |
Andrew M. Kuchling | 6a360bd | 2001-02-05 02:47:52 +0000 | [diff] [blame] | 15 | the final version of Python 2.1 is released. Currently it is up to date |
Andrew M. Kuchling | 74d18ed | 2001-02-28 22:22:40 +0000 | [diff] [blame] | 16 | for Python 2.1 beta 1. Please send any comments, bug reports, or |
Andrew M. Kuchling | 6a360bd | 2001-02-05 02:47:52 +0000 | [diff] [blame] | 17 | questions, no matter how minor, to \email{amk1@bigfoot.com}. } |
Andrew M. Kuchling | f33c118 | 2001-01-23 02:48:26 +0000 | [diff] [blame] | 18 | |
Andrew M. Kuchling | 90cecee | 2001-01-22 04:02:09 +0000 | [diff] [blame] | 19 | It's that time again... time for a new Python release, version 2.1. |
| 20 | One recent goal of the Python development team has been to accelerate |
| 21 | the pace of new releases, with a new release coming every 6 to 9 |
| 22 | months. 2.1 is the first release to come out at this faster pace, with |
| 23 | the first alpha appearing in January, 3 months after the final version |
| 24 | of 2.0 was released. |
| 25 | |
| 26 | This article explains the new features in 2.1. While there aren't as |
| 27 | many changes in 2.1 as there were in Python 2.0, there are still some |
| 28 | pleasant surprises in store. 2.1 is the first release to be steered |
| 29 | through the use of Python Enhancement Proposals, or PEPs, so most of |
| 30 | the sizable changes have accompanying PEPs that provide more complete |
| 31 | documentation and a design rationale for the change. This article |
| 32 | doesn't attempt to document the new features completely, but simply |
| 33 | provides an overview of the new features for Python programmers. |
| 34 | Refer to the Python 2.1 documentation, or to the specific PEP, for |
| 35 | more details about any new feature that particularly interests you. |
| 36 | |
Andrew M. Kuchling | 8bad993 | 2001-02-28 22:39:15 +0000 | [diff] [blame] | 37 | Currently 2.1 is available in a beta release, and the final release is |
| 38 | planned for April 2001. |
Andrew M. Kuchling | 90cecee | 2001-01-22 04:02:09 +0000 | [diff] [blame] | 39 | |
Andrew M. Kuchling | 6a360bd | 2001-02-05 02:47:52 +0000 | [diff] [blame] | 40 | %====================================================================== |
| 41 | \section{PEP 227: Nested Scopes} |
| 42 | |
| 43 | The largest change in Python 2.1 is to Python's scoping rules. In |
| 44 | Python 2.0, at any given time there are at most three namespaces used |
| 45 | to look up variable names: local, module-level, and the built-in |
| 46 | namespace. This often surprised people because it didn't match their |
| 47 | intuitive expectations. For example, a nested recursive function |
| 48 | definition doesn't work: |
| 49 | |
| 50 | \begin{verbatim} |
| 51 | def f(): |
| 52 | ... |
| 53 | def g(value): |
| 54 | ... |
| 55 | return g(value-1) + 1 |
| 56 | ... |
| 57 | \end{verbatim} |
| 58 | |
| 59 | The function \function{g()} will always raise a \exception{NameError} |
| 60 | exception, because the binding of the name \samp{g} isn't in either |
| 61 | its local namespace or in the module-level namespace. This isn't much |
| 62 | of a problem in practice (how often do you recursively define interior |
| 63 | functions like this?), but this also made using the \keyword{lambda} |
| 64 | statement clumsier, and this was a problem in practice. In code which |
| 65 | uses \keyword{lambda} you can often find local variables being copied |
| 66 | by passing them as the default values of arguments. |
| 67 | |
| 68 | \begin{verbatim} |
| 69 | def find(self, name): |
| 70 | "Return list of any entries equal to 'name'" |
| 71 | L = filter(lambda x, name=name: x == name, |
| 72 | self.list_attribute) |
| 73 | return L |
| 74 | \end{verbatim} |
| 75 | |
| 76 | The readability of Python code written in a strongly functional style |
| 77 | suffers greatly as a result. |
| 78 | |
| 79 | The most significant change to Python 2.1 is that static scoping has |
| 80 | been added to the language to fix this problem. As a first effect, |
| 81 | the \code{name=name} default argument is now unnecessary in the above |
| 82 | example. Put simply, when a given variable name is not assigned a |
| 83 | value within a function (by an assignment, or the \keyword{def}, |
| 84 | \keyword{class}, or \keyword{import} statements), references to the |
| 85 | variable will be looked up in the local namespace of the enclosing |
| 86 | scope. A more detailed explanation of the rules, and a dissection of |
| 87 | the implementation, can be found in the PEP. |
| 88 | |
| 89 | This change may cause some compatibility problems for code where the |
| 90 | same variable name is used both at the module level and as a local |
| 91 | variable within a function that contains further function definitions. |
| 92 | This seems rather unlikely though, since such code would have been |
| 93 | pretty confusing to read in the first place. |
| 94 | |
Andrew M. Kuchling | 15ad28c | 2001-02-14 02:44:18 +0000 | [diff] [blame] | 95 | One side effect of the change is that the \code{from \var{module} |
| 96 | import *} and \keyword{exec} statements have been made illegal inside |
| 97 | a function scope under certain conditions. The Python reference |
| 98 | manual has said all along that \code{from \var{module} import *} is |
| 99 | only legal at the top level of a module, but the CPython interpreter |
| 100 | has never enforced this before. As part of the implementation of |
| 101 | nested scopes, the compiler which turns Python source into bytecodes |
| 102 | has to generate different code to access variables in a containing |
| 103 | scope. \code{from \var{module} import *} and \keyword{exec} make it |
| 104 | impossible for the compiler to figure this out, because they add names |
| 105 | to the local namespace that are unknowable at compile time. |
| 106 | Therefore, if a function contains function definitions or |
| 107 | \keyword{lambda} expressions with free variables, the compiler will |
| 108 | flag this by raising a \exception{SyntaxError} exception. |
| 109 | |
| 110 | To make the preceding explanation a bit clearer, here's an example: |
| 111 | |
| 112 | \begin{verbatim} |
| 113 | x = 1 |
| 114 | def f(): |
| 115 | # The next line is a syntax error |
| 116 | exec 'x=2' |
| 117 | def g(): |
| 118 | return x |
| 119 | \end{verbatim} |
| 120 | |
| 121 | Line 4 containing the \keyword{exec} statement is a syntax error, |
| 122 | since \keyword{exec} would define a new local variable named \samp{x} |
| 123 | whose value should be accessed by \function{g()}. |
| 124 | |
| 125 | This shouldn't be much of a limitation, since \keyword{exec} is rarely |
| 126 | used in most Python code (and when it is used, it's often a sign of a |
| 127 | poor design anyway). |
Andrew M. Kuchling | 6a360bd | 2001-02-05 02:47:52 +0000 | [diff] [blame] | 128 | |
| 129 | \begin{seealso} |
| 130 | |
| 131 | \seepep{227}{Statically Nested Scopes}{Written and implemented by |
| 132 | Jeremy Hylton.} |
| 133 | |
| 134 | \end{seealso} |
| 135 | |
| 136 | |
| 137 | %====================================================================== |
Andrew M. Kuchling | 74d18ed | 2001-02-28 22:22:40 +0000 | [diff] [blame] | 138 | \section{PEP 236: \module{__future__} Directives} |
Andrew M. Kuchling | 90cecee | 2001-01-22 04:02:09 +0000 | [diff] [blame] | 139 | |
Andrew M. Kuchling | 74d18ed | 2001-02-28 22:22:40 +0000 | [diff] [blame] | 140 | XXX |
Andrew M. Kuchling | f228fd1 | 2001-01-22 17:52:19 +0000 | [diff] [blame] | 141 | |
Andrew M. Kuchling | 6a360bd | 2001-02-05 02:47:52 +0000 | [diff] [blame] | 142 | %====================================================================== |
Andrew M. Kuchling | 90cecee | 2001-01-22 04:02:09 +0000 | [diff] [blame] | 143 | \section{PEP 207: Rich Comparisons} |
| 144 | |
Andrew M. Kuchling | b216ab6 | 2001-01-22 16:15:44 +0000 | [diff] [blame] | 145 | In earlier versions, Python's support for implementing comparisons on |
| 146 | user-defined classes and extension types was quite simple. Classes |
| 147 | could implement a \method{__cmp__} method that was given two instances |
| 148 | of a class, and could only return 0 if they were equal or +1 or -1 if |
| 149 | they weren't; the method couldn't raise an exception or return |
| 150 | anything other than a Boolean value. Users of Numeric Python often |
| 151 | found this model too weak and restrictive, because in the |
| 152 | number-crunching programs that numeric Python is used for, it would be |
| 153 | more useful to be able to perform elementwise comparisons of two |
| 154 | matrices, returning a matrix containing the results of a given |
| 155 | comparison for each element. If the two matrices are of different |
| 156 | sizes, then the compare has to be able to raise an exception to signal |
| 157 | the error. |
| 158 | |
Andrew M. Kuchling | 6a360bd | 2001-02-05 02:47:52 +0000 | [diff] [blame] | 159 | In Python 2.1, rich comparisons were added in order to support this |
| 160 | need. Python classes can now individually overload each of the |
| 161 | \code{<}, \code{<=}, \code{>}, \code{>=}, \code{==}, and \code{!=} |
| 162 | operations. The new magic method names are: |
Andrew M. Kuchling | b216ab6 | 2001-01-22 16:15:44 +0000 | [diff] [blame] | 163 | |
| 164 | \begin{tableii}{c|l}{code}{Operation}{Method name} |
Andrew M. Kuchling | 6a360bd | 2001-02-05 02:47:52 +0000 | [diff] [blame] | 165 | \lineii{<}{\method{__lt__}} \lineii{<=}{\method{__le__}} |
| 166 | \lineii{>}{\method{__gt__}} \lineii{>=}{\method{__ge__}} |
| 167 | \lineii{==}{\method{__eq__}} \lineii{!=}{\method{__ne__}} |
| 168 | \end{tableii} |
Andrew M. Kuchling | b216ab6 | 2001-01-22 16:15:44 +0000 | [diff] [blame] | 169 | |
| 170 | (The magic methods are named after the corresponding Fortran operators |
| 171 | \code{.LT.}. \code{.LE.}, \&c. Numeric programmers are almost |
| 172 | certainly quite familar with these names and will find them easy to |
| 173 | remember.) |
| 174 | |
| 175 | Each of these magic methods is of the form \code{\var{method}(self, |
| 176 | other)}, where \code{self} will be the object on the left-hand side of |
| 177 | the operator, while \code{other} will be the object on the right-hand |
| 178 | side. For example, the expression \code{A < B} will cause |
| 179 | \code{A.__lt__(B)} to be called. |
| 180 | |
| 181 | Each of these magic methods can return anything at all: a Boolean, a |
| 182 | matrix, a list, or any other Python object. Alternatively they can |
| 183 | raise an exception if the comparison is impossible, inconsistent, or |
| 184 | otherwise meaningless. |
| 185 | |
| 186 | The built-in \function{cmp(A,B)} function can use the rich comparison |
| 187 | machinery, and now accepts an optional argument specifying which |
| 188 | comparison operation to use; this is given as one of the strings |
| 189 | \code{"<"}, \code{"<="}, \code{">"}, \code{">="}, \code{"=="}, or |
| 190 | \code{"!="}. If called without the optional third argument, |
| 191 | \function{cmp()} will only return -1, 0, or +1 as in previous versions |
| 192 | of Python; otherwise it will call the appropriate method and can |
| 193 | return any Python object. |
| 194 | |
| 195 | There are also corresponding changes of interest to C programmers; |
| 196 | there's a new slot \code{tp_richcmp} in type objects and an API for |
| 197 | performing a given rich comparison. I won't cover the C API here, but |
Andrew M. Kuchling | bf14014 | 2001-02-28 22:10:07 +0000 | [diff] [blame] | 198 | will refer you to PEP 207, or to 2.1's C API documentation, for the |
| 199 | full list of related functions. |
Andrew M. Kuchling | b216ab6 | 2001-01-22 16:15:44 +0000 | [diff] [blame] | 200 | |
| 201 | \begin{seealso} |
| 202 | |
| 203 | \seepep{207}{Rich Comparisions}{Written by Guido van Rossum, heavily |
Andrew M. Kuchling | 6a360bd | 2001-02-05 02:47:52 +0000 | [diff] [blame] | 204 | based on earlier work by David Ascher, and implemented by Guido van |
| 205 | Rossum.} |
Andrew M. Kuchling | b216ab6 | 2001-01-22 16:15:44 +0000 | [diff] [blame] | 206 | |
| 207 | \end{seealso} |
Andrew M. Kuchling | 90cecee | 2001-01-22 04:02:09 +0000 | [diff] [blame] | 208 | |
Andrew M. Kuchling | 6a360bd | 2001-02-05 02:47:52 +0000 | [diff] [blame] | 209 | %====================================================================== |
Andrew M. Kuchling | 90cecee | 2001-01-22 04:02:09 +0000 | [diff] [blame] | 210 | \section{PEP 230: Warning Framework} |
| 211 | |
| 212 | Over its 10 years of existence, Python has accumulated a certain |
| 213 | number of obsolete modules and features along the way. It's difficult |
| 214 | to know when a feature is safe to remove, since there's no way of |
Andrew M. Kuchling | f33c118 | 2001-01-23 02:48:26 +0000 | [diff] [blame] | 215 | knowing how much code uses it --- perhaps no programs depend on the |
Andrew M. Kuchling | 90cecee | 2001-01-22 04:02:09 +0000 | [diff] [blame] | 216 | feature, or perhaps many do. To enable removing old features in a |
| 217 | more structured way, a warning framework was added. When the Python |
| 218 | developers want to get rid of a feature, it will first trigger a |
| 219 | warning in the next version of Python. The following Python version |
| 220 | can then drop the feature, and users will have had a full release |
Andrew M. Kuchling | 6a360bd | 2001-02-05 02:47:52 +0000 | [diff] [blame] | 221 | cycle to remove uses of the old feature. |
Andrew M. Kuchling | 90cecee | 2001-01-22 04:02:09 +0000 | [diff] [blame] | 222 | |
| 223 | Python 2.1 adds the warning framework to be used in this scheme. It |
| 224 | adds a \module{warnings} module that provide functions to issue |
| 225 | warnings, and to filter out warnings that you don't want to be |
| 226 | displayed. Third-party modules can also use this framework to |
| 227 | deprecate old features that they no longer wish to support. |
| 228 | |
Andrew M. Kuchling | 6a360bd | 2001-02-05 02:47:52 +0000 | [diff] [blame] | 229 | For example, in Python 2.1 the \module{regex} module is deprecated, so |
| 230 | importing it causes a warning to be printed: |
Andrew M. Kuchling | 90cecee | 2001-01-22 04:02:09 +0000 | [diff] [blame] | 231 | |
| 232 | \begin{verbatim} |
| 233 | >>> import regex |
Andrew M. Kuchling | 6a360bd | 2001-02-05 02:47:52 +0000 | [diff] [blame] | 234 | __main__:1: DeprecationWarning: the regex module |
| 235 | is deprecated; please use the re module |
| 236 | >>> |
Andrew M. Kuchling | 90cecee | 2001-01-22 04:02:09 +0000 | [diff] [blame] | 237 | \end{verbatim} |
| 238 | |
Andrew M. Kuchling | 6a360bd | 2001-02-05 02:47:52 +0000 | [diff] [blame] | 239 | Warnings can be issued by calling the \function{warnings.warn} |
| 240 | function: |
Andrew M. Kuchling | 90cecee | 2001-01-22 04:02:09 +0000 | [diff] [blame] | 241 | |
| 242 | \begin{verbatim} |
Andrew M. Kuchling | 6a360bd | 2001-02-05 02:47:52 +0000 | [diff] [blame] | 243 | warnings.warn("feature X no longer supported") |
Andrew M. Kuchling | 90cecee | 2001-01-22 04:02:09 +0000 | [diff] [blame] | 244 | \end{verbatim} |
| 245 | |
| 246 | The first parameter is the warning message; an additional optional |
| 247 | parameters can be used to specify a particular warning category. |
| 248 | |
| 249 | Filters can be added to disable certain warnings; a regular expression |
| 250 | pattern can be applied to the message or to the module name in order |
| 251 | to suppress a warning. For example, you may have a program that uses |
| 252 | the \module{regex} module and not want to spare the time to convert it |
Andrew M. Kuchling | b216ab6 | 2001-01-22 16:15:44 +0000 | [diff] [blame] | 253 | to use the \module{re} module right now. The warning can be |
| 254 | suppressed by calling |
Andrew M. Kuchling | 90cecee | 2001-01-22 04:02:09 +0000 | [diff] [blame] | 255 | |
| 256 | \begin{verbatim} |
Andrew M. Kuchling | b216ab6 | 2001-01-22 16:15:44 +0000 | [diff] [blame] | 257 | import warnings |
| 258 | warnings.filterwarnings(action = 'ignore', |
| 259 | message='.*regex module is deprecated', |
| 260 | category=DeprecationWarning, |
| 261 | module = '__main__') |
Andrew M. Kuchling | 90cecee | 2001-01-22 04:02:09 +0000 | [diff] [blame] | 262 | \end{verbatim} |
| 263 | |
Andrew M. Kuchling | b216ab6 | 2001-01-22 16:15:44 +0000 | [diff] [blame] | 264 | This adds a filter that will apply only to warnings of the class |
Andrew M. Kuchling | 6a360bd | 2001-02-05 02:47:52 +0000 | [diff] [blame] | 265 | \class{DeprecationWarning} triggered in the \module{__main__} module, |
| 266 | and applies a regular expression to only match the message about the |
| 267 | \module{regex} module being deprecated, and will cause such warnings |
| 268 | to be ignored. Warnings can also be printed only once, printed every |
| 269 | time the offending code is executed, or turned into exceptions that |
| 270 | will cause the program to stop (unless the exceptions are caught in |
| 271 | the usual way, of course). |
Andrew M. Kuchling | b216ab6 | 2001-01-22 16:15:44 +0000 | [diff] [blame] | 272 | |
Andrew M. Kuchling | 90cecee | 2001-01-22 04:02:09 +0000 | [diff] [blame] | 273 | Functions were also added to Python's C API for issuing warnings; |
Andrew M. Kuchling | b216ab6 | 2001-01-22 16:15:44 +0000 | [diff] [blame] | 274 | refer to PEP 230 or to Python's API documentation for the details. |
Andrew M. Kuchling | 90cecee | 2001-01-22 04:02:09 +0000 | [diff] [blame] | 275 | |
Andrew M. Kuchling | 6a360bd | 2001-02-05 02:47:52 +0000 | [diff] [blame] | 276 | \begin{seealso} |
Andrew M. Kuchling | 90cecee | 2001-01-22 04:02:09 +0000 | [diff] [blame] | 277 | |
Andrew M. Kuchling | 6a360bd | 2001-02-05 02:47:52 +0000 | [diff] [blame] | 278 | \seepep{5}{Guidelines for Language Evolution}{Written |
| 279 | by Paul Prescod, to specify procedures to be followed when removing |
| 280 | old features from Python. The policy described in this PEP hasn't |
| 281 | been officially adopted, but the eventual policy probably won't be too |
| 282 | different from Prescod's proposal.} |
| 283 | |
| 284 | \seepep{230}{Warning Framework}{Written and implemented by Guido van |
| 285 | Rossum.} |
| 286 | |
Andrew M. Kuchling | b216ab6 | 2001-01-22 16:15:44 +0000 | [diff] [blame] | 287 | \end{seealso} |
Andrew M. Kuchling | 90cecee | 2001-01-22 04:02:09 +0000 | [diff] [blame] | 288 | |
Andrew M. Kuchling | 6a360bd | 2001-02-05 02:47:52 +0000 | [diff] [blame] | 289 | %====================================================================== |
Andrew M. Kuchling | 90cecee | 2001-01-22 04:02:09 +0000 | [diff] [blame] | 290 | \section{PEP 229: New Build System} |
| 291 | |
| 292 | When compiling Python, the user had to go in and edit the |
| 293 | \file{Modules/Setup} file in order to enable various additional |
| 294 | modules; the default set is relatively small and limited to modules |
| 295 | that compile on most Unix platforms. This means that on Unix |
| 296 | platforms with many more features, most notably Linux, Python |
| 297 | installations often don't contain all useful modules they could. |
| 298 | |
| 299 | Python 2.0 added the Distutils, a set of modules for distributing and |
| 300 | installing extensions. In Python 2.1, the Distutils are used to |
| 301 | compile much of the standard library of extension modules, |
Andrew M. Kuchling | f33c118 | 2001-01-23 02:48:26 +0000 | [diff] [blame] | 302 | autodetecting which ones are supported on the current machine. It's |
| 303 | hoped that this will make Python installations easier and more |
| 304 | featureful. |
| 305 | |
| 306 | Instead of having to edit the \file{Modules/Setup} file in order to |
| 307 | enable modules, a \file{setup.py} script in the top directory of the |
| 308 | Python source distribution is run at build time, and attempts to |
| 309 | discover which modules can be enabled by examining the modules and |
Andrew M. Kuchling | 8bad993 | 2001-02-28 22:39:15 +0000 | [diff] [blame] | 310 | header files on the system. If a module is configured in |
| 311 | \file{Modules/Setup}, the \file{setup.py} script won't attempt to |
| 312 | compile that module and will defer to the \file{Modules/Setup} file's |
| 313 | contents. This provides a way to specific any strange command-line |
| 314 | flags or libraries that are required for a specific platform. |
Andrew M. Kuchling | 90cecee | 2001-01-22 04:02:09 +0000 | [diff] [blame] | 315 | |
Andrew M. Kuchling | 4308d3c | 2001-01-29 17:36:53 +0000 | [diff] [blame] | 316 | In another far-reaching change to the build mechanism, Neil |
| 317 | Schemenauer restructured things so Python now uses a single makefile |
| 318 | that isn't recursive, instead of makefiles in the top directory and in |
Andrew M. Kuchling | 8bad993 | 2001-02-28 22:39:15 +0000 | [diff] [blame] | 319 | each of the \file{Python/}, \file{Parser/}, \file{Objects/}, and |
| 320 | \file{Modules/} subdirectories. This makes building Python faster |
| 321 | and also makes hacking the Makefiles clearer and simpler. |
Andrew M. Kuchling | 4308d3c | 2001-01-29 17:36:53 +0000 | [diff] [blame] | 322 | |
Andrew M. Kuchling | 6a360bd | 2001-02-05 02:47:52 +0000 | [diff] [blame] | 323 | \begin{seealso} |
| 324 | |
| 325 | \seepep{229}{Using Distutils to Build Python}{Written |
| 326 | and implemented by A.M. Kuchling.} |
| 327 | |
Andrew M. Kuchling | b216ab6 | 2001-01-22 16:15:44 +0000 | [diff] [blame] | 328 | \end{seealso} |
Andrew M. Kuchling | 90cecee | 2001-01-22 04:02:09 +0000 | [diff] [blame] | 329 | |
Andrew M. Kuchling | 6a360bd | 2001-02-05 02:47:52 +0000 | [diff] [blame] | 330 | %====================================================================== |
Andrew M. Kuchling | 15ad28c | 2001-02-14 02:44:18 +0000 | [diff] [blame] | 331 | \section{PEP 205: Weak References} |
Andrew M. Kuchling | 6a360bd | 2001-02-05 02:47:52 +0000 | [diff] [blame] | 332 | |
Andrew M. Kuchling | 15ad28c | 2001-02-14 02:44:18 +0000 | [diff] [blame] | 333 | Weak references, available through the \module{weakref} module, are a |
| 334 | minor but useful new data type in the Python programmer's toolbox. |
Andrew M. Kuchling | 6a360bd | 2001-02-05 02:47:52 +0000 | [diff] [blame] | 335 | |
Andrew M. Kuchling | 15ad28c | 2001-02-14 02:44:18 +0000 | [diff] [blame] | 336 | Storing a reference to an object (say, in a dictionary or a list) has |
| 337 | the side effect of keeping that object alive forever. There are a few |
| 338 | specific cases where this behaviour is undesirable, object caches |
| 339 | being the most common one, and another being circular references in |
| 340 | data structures such as trees. |
Andrew M. Kuchling | 6a360bd | 2001-02-05 02:47:52 +0000 | [diff] [blame] | 341 | |
Andrew M. Kuchling | 15ad28c | 2001-02-14 02:44:18 +0000 | [diff] [blame] | 342 | For example, consider a memoizing function that caches the results of |
| 343 | another function \function{f(\var{x})} by storing the function's |
| 344 | argument and its result in a dictionary: |
| 345 | |
| 346 | \begin{verbatim} |
| 347 | _cache = {} |
| 348 | def memoize(x): |
| 349 | if _cache.has_key(x): |
| 350 | return _cache[x] |
| 351 | |
| 352 | retval = f(x) |
| 353 | |
| 354 | # Cache the returned object |
| 355 | _cache[x] = retval |
| 356 | |
| 357 | return retval |
| 358 | \end{verbatim} |
| 359 | |
| 360 | This version works for simple things such as integers, but it has a |
| 361 | side effect; the \code{_cache} dictionary holds a reference to the |
| 362 | return values, so they'll never be deallocated until the Python |
| 363 | process exits and cleans up This isn't very noticeable for integers, |
| 364 | but if \function{f()} returns an object, or a data structure that |
| 365 | takes up a lot of memory, this can be a problem. |
| 366 | |
| 367 | Weak references provide a way to implement a cache that won't keep |
| 368 | objects alive beyond their time. If an object is only accessible |
| 369 | through weak references, the object will be deallocated and the weak |
| 370 | references will now indicate that the object it referred to no longer |
| 371 | exists. A weak reference to an object \var{obj} is created by calling |
| 372 | \code{wr = weakref.ref(\var{obj})}. The object being referred to is |
| 373 | returned by calling the weak reference as if it were a function: |
| 374 | \code{wr()}. It will return the referenced object, or \code{None} if |
| 375 | the object no longer exists. |
| 376 | |
| 377 | This makes it possible to write a \function{memoize()} function whose |
| 378 | cache doesn't keep objects alive, by storing weak references in the |
| 379 | cache. |
| 380 | |
| 381 | \begin{verbatim} |
| 382 | _cache = {} |
| 383 | def memoize(x): |
| 384 | if _cache.has_key(x): |
| 385 | obj = _cache[x]() |
| 386 | # If weak reference object still exists, |
| 387 | # return it |
| 388 | if obj is not None: return obj |
| 389 | |
| 390 | retval = f(x) |
| 391 | |
| 392 | # Cache a weak reference |
| 393 | _cache[x] = weakref.ref(retval) |
| 394 | |
| 395 | return retval |
| 396 | \end{verbatim} |
| 397 | |
| 398 | The \module{weakref} module also allows creating proxy objects which |
| 399 | behave like weak references --- an object referenced only by proxy |
| 400 | objects is deallocated -- but instead of requiring an explicit call to |
| 401 | retrieve the object, the proxy transparently forwards all operations |
| 402 | to the object as long as the object still exists. If the object is |
| 403 | deallocated, attempting to use a proxy will cause a |
| 404 | \exception{weakref.ReferenceError} exception to be raised. |
| 405 | |
| 406 | \begin{verbatim} |
| 407 | proxy = weakref.proxy(obj) |
| 408 | proxy.attr # Equivalent to obj.attr |
| 409 | proxy.meth() # Equivalent to obj.meth() |
| 410 | del obj |
| 411 | proxy.attr # raises weakref.ReferenceError |
| 412 | \end{verbatim} |
Andrew M. Kuchling | 6a360bd | 2001-02-05 02:47:52 +0000 | [diff] [blame] | 413 | |
| 414 | \begin{seealso} |
| 415 | |
| 416 | \seepep{205}{Weak References}{Written and implemented by |
| 417 | Fred~L. Drake,~Jr.} |
| 418 | |
| 419 | \end{seealso} |
| 420 | |
| 421 | %====================================================================== |
Andrew M. Kuchling | 74d18ed | 2001-02-28 22:22:40 +0000 | [diff] [blame] | 422 | \section{PEP 235: Case-Insensitive Platforms and \keyword{import}} |
| 423 | |
Andrew M. Kuchling | 8bad993 | 2001-02-28 22:39:15 +0000 | [diff] [blame] | 424 | Some operating systems have filesystems that are case-insensitive, |
| 425 | MacOS and Windows being the primary examples; on these systems, it's |
| 426 | impossible to distinguish the filenames \samp{FILE.PY} and |
| 427 | \samp{file.py}, even though they do store the file's name |
| 428 | in its original case (they're case-preserving, too). |
| 429 | |
| 430 | In Python 2.1, the \keyword{import} statement will work to simulate |
| 431 | case-sensitivity on case-insensitive platforms. Python will now |
| 432 | search for the first case-sensitive match by default, raising an |
| 433 | \exception{ImportError} if no such file is found, so \code{import file} |
| 434 | will not import a module named \samp{FILE.PY}. Case-insensitive |
| 435 | matching can be requested by setting the PYTHONCASEOK environment |
| 436 | variable before starting the Python interpreter. |
Andrew M. Kuchling | 74d18ed | 2001-02-28 22:22:40 +0000 | [diff] [blame] | 437 | |
| 438 | %====================================================================== |
Andrew M. Kuchling | 90cecee | 2001-01-22 04:02:09 +0000 | [diff] [blame] | 439 | \section{PEP 217: Interactive Display Hook} |
| 440 | |
| 441 | When using the Python interpreter interactively, the output of |
| 442 | commands is displayed using the built-in \function{repr()} function. |
| 443 | In Python 2.1, the variable \module{sys.displayhook} can be set to a |
| 444 | callable object which will be called instead of \function{repr()}. |
| 445 | For example, you can set it to a special pretty-printing function: |
| 446 | |
| 447 | \begin{verbatim} |
Andrew M. Kuchling | b216ab6 | 2001-01-22 16:15:44 +0000 | [diff] [blame] | 448 | >>> # Create a recursive data structure |
| 449 | ... L = [1,2,3] |
| 450 | >>> L.append(L) |
Andrew M. Kuchling | 6a360bd | 2001-02-05 02:47:52 +0000 | [diff] [blame] | 451 | >>> L # Show Python's default output |
Andrew M. Kuchling | b216ab6 | 2001-01-22 16:15:44 +0000 | [diff] [blame] | 452 | [1, 2, 3, [...]] |
| 453 | >>> # Use pprint.pprint() as the display function |
| 454 | ... import sys, pprint |
| 455 | >>> sys.displayhook = pprint.pprint |
| 456 | >>> L |
Andrew M. Kuchling | 6a360bd | 2001-02-05 02:47:52 +0000 | [diff] [blame] | 457 | [1, 2, 3, <Recursion on list with id=135143996>] |
| 458 | >>> |
Andrew M. Kuchling | 90cecee | 2001-01-22 04:02:09 +0000 | [diff] [blame] | 459 | \end{verbatim} |
| 460 | |
Andrew M. Kuchling | b216ab6 | 2001-01-22 16:15:44 +0000 | [diff] [blame] | 461 | \begin{seealso} |
| 462 | |
Andrew M. Kuchling | 6a360bd | 2001-02-05 02:47:52 +0000 | [diff] [blame] | 463 | \seepep{217}{Display Hook for Interactive Use}{Written and implemented |
| 464 | by Moshe Zadka.} |
Andrew M. Kuchling | 90cecee | 2001-01-22 04:02:09 +0000 | [diff] [blame] | 465 | |
Andrew M. Kuchling | b216ab6 | 2001-01-22 16:15:44 +0000 | [diff] [blame] | 466 | \end{seealso} |
| 467 | |
Andrew M. Kuchling | 6a360bd | 2001-02-05 02:47:52 +0000 | [diff] [blame] | 468 | %====================================================================== |
Andrew M. Kuchling | 90cecee | 2001-01-22 04:02:09 +0000 | [diff] [blame] | 469 | \section{PEP 208: New Coercion Model} |
| 470 | |
| 471 | How numeric coercion is done at the C level was significantly |
| 472 | modified. This will only affect the authors of C extensions to |
| 473 | Python, allowing them more flexibility in writing extension types that |
| 474 | support numeric operations. |
| 475 | |
Andrew M. Kuchling | 6a360bd | 2001-02-05 02:47:52 +0000 | [diff] [blame] | 476 | Extension types can now set the type flag \code{Py_TPFLAGS_CHECKTYPES} |
| 477 | in their \code{PyTypeObject} structure to indicate that they support |
| 478 | the new coercion model. In such extension types, the numeric slot |
| 479 | functions can no longer assume that they'll be passed two arguments of |
| 480 | the same type; instead they may be passed two arguments of differing |
| 481 | types, and can then perform their own internal coercion. If the slot |
| 482 | function is passed a type it can't handle, it can indicate the failure |
| 483 | by returning a reference to the \code{Py_NotImplemented} singleton |
| 484 | value. The numeric functions of the other type will then be tried, |
| 485 | and perhaps they can handle the operation; if the other type also |
| 486 | returns \code{Py_NotImplemented}, then a \exception{TypeError} will be |
| 487 | raised. Numeric methods written in Python can also return |
| 488 | \code{Py_NotImplemented}, causing the interpreter to act as if the |
| 489 | method did not exist (perhaps raising a \exception{TypeError}, perhaps |
| 490 | trying another object's numeric methods). |
Andrew M. Kuchling | 90cecee | 2001-01-22 04:02:09 +0000 | [diff] [blame] | 491 | |
Andrew M. Kuchling | b216ab6 | 2001-01-22 16:15:44 +0000 | [diff] [blame] | 492 | \begin{seealso} |
| 493 | |
Andrew M. Kuchling | 90cecee | 2001-01-22 04:02:09 +0000 | [diff] [blame] | 494 | \seepep{208}{Reworking the Coercion Model}{Written and implemented by |
| 495 | Neil Schemenauer, heavily based upon earlier work by Marc-Andr\'e |
| 496 | Lemburg. Read this to understand the fine points of how numeric |
| 497 | operations will now be processed at the C level.} |
| 498 | |
Andrew M. Kuchling | b216ab6 | 2001-01-22 16:15:44 +0000 | [diff] [blame] | 499 | \end{seealso} |
Andrew M. Kuchling | 90cecee | 2001-01-22 04:02:09 +0000 | [diff] [blame] | 500 | |
Andrew M. Kuchling | 6a360bd | 2001-02-05 02:47:52 +0000 | [diff] [blame] | 501 | %====================================================================== |
Andrew M. Kuchling | 81b6ae7 | 2001-02-11 16:55:39 +0000 | [diff] [blame] | 502 | \section{New and Improved Modules} |
| 503 | |
| 504 | \begin{itemize} |
| 505 | |
Andrew M. Kuchling | 74d18ed | 2001-02-28 22:22:40 +0000 | [diff] [blame] | 506 | \item Ka-Ping Yee contributed two new modules: \module{inspect.py}, a module for |
| 507 | getting information about live Python code, and \module{pydoc.py}, a |
| 508 | module for interactively converting docstrings to HTML or text. |
| 509 | As a bonus, \file{Tools/scripts/pydoc}, which is now automatically |
| 510 | installed, uses \module{pydoc.py} to display documentation given a Python module, package, or class name. For example, |
| 511 | \samp{pydoc xml.dom} displays the following: |
| 512 | |
| 513 | \begin{verbatim} |
| 514 | Python Library Documentation: package xml.dom in xml |
| 515 | |
| 516 | NAME |
| 517 | xml.dom - W3C Document Object Model implementation for Python. |
| 518 | |
| 519 | FILE |
| 520 | /usr/local/lib/python2.1/xml/dom/__init__.pyc |
| 521 | |
| 522 | DESCRIPTION |
| 523 | The Python mapping of the Document Object Model is documented in the |
| 524 | Python Library Reference in the section on the xml.dom package. |
| 525 | |
| 526 | This package contains the following modules: |
| 527 | ... |
| 528 | \end{verbatim} |
| 529 | |
| 530 | \file{pydoc} quickly becomes addictive; try it out! |
| 531 | |
Andrew M. Kuchling | 15ad28c | 2001-02-14 02:44:18 +0000 | [diff] [blame] | 532 | \item The \module{doctest} module provides a testing framework based |
| 533 | on running embedded examples in docstrings and comparing the results |
| 534 | against the expected output. Contributed by Tim Peters. |
| 535 | |
| 536 | \item The \module{difflib} module contains a class, |
| 537 | \class{SequenceMatcher}, which compares two sequences and computes the |
| 538 | changes required to transform one sequence into the other. For |
| 539 | example, this module can be used to write a tool similar to the Unix |
| 540 | \program{diff} program, and in fact the sample program |
| 541 | \file{Tools/scripts/ndiff.py} demonstrates how to write such a script. |
| 542 | |
Andrew M. Kuchling | 81b6ae7 | 2001-02-11 16:55:39 +0000 | [diff] [blame] | 543 | \item \module{curses.panel}, a wrapper for the panel library, part of |
| 544 | ncurses and of SYSV curses, was contributed by Thomas Gellekum. The |
| 545 | panel library provides windows with the additional feature of depth. |
| 546 | Windows can be moved higher or lower in the depth ordering, and the |
| 547 | panel library figures out where panels overlap and which sections are |
| 548 | visible. |
| 549 | |
| 550 | \item The PyXML package has gone through a few releases since Python |
| 551 | 2.0, and Python 2.1 includes an updated version of the \module{xml} |
Andrew M. Kuchling | 74d18ed | 2001-02-28 22:22:40 +0000 | [diff] [blame] | 552 | package. Some of the noteworthy changes include support for Expat 1.2 |
| 553 | and later versions, the ability for Expat parsers to handle files in |
| 554 | any encoding supported by Python, and various bugfixes for SAX, DOM, |
| 555 | and the \module{minidom} module. |
Andrew M. Kuchling | 81b6ae7 | 2001-02-11 16:55:39 +0000 | [diff] [blame] | 556 | |
| 557 | \item Various functions in the \module{time} module, such as |
| 558 | \function{asctime()} and \function{localtime()}, require a floating |
| 559 | point argument containing the time in seconds since the epoch. The |
| 560 | most common use of these functions is to work with the current time, |
| 561 | so the floating point argument has been made optional; when a value |
| 562 | isn't provided, the current time will be used. For example, log file |
| 563 | entries usually need a string containing the current time; in Python |
| 564 | 2.1, \code{time.asctime()} can be used, instead of the lengthier |
| 565 | \code{time.asctime(time.localtime(time.time()))} that was previously |
| 566 | required. |
| 567 | |
| 568 | This change was proposed and implemented by Thomas Wouters. |
| 569 | |
| 570 | \item The \module{ftplib} module now defaults to retrieving files in |
| 571 | passive mode, because passive mode is more likely to work from behind |
| 572 | a firewall. This request came from the Debian bug tracking system, |
| 573 | since other Debian packages use \module{ftplib} to retrieve files and |
| 574 | then don't work from behind a firewall. It's deemed unlikely that |
| 575 | this will cause problems for anyone, because Netscape defaults to |
| 576 | passive mode and few people complain, but if passive mode is |
| 577 | unsuitable for your application or network setup, call |
| 578 | \method{set_pasv(0)} on FTP objects to disable passive mode. |
| 579 | |
| 580 | \item Support for raw socket access has been added to the |
| 581 | \module{socket} module, contributed by Grant Edwards. |
| 582 | |
Andrew M. Kuchling | 15ad28c | 2001-02-14 02:44:18 +0000 | [diff] [blame] | 583 | \item A new implementation-dependent function, \function{sys._getframe(\optional{depth})}, |
| 584 | has been added to return a given frame object from the current call stack. |
| 585 | \function{sys._getframe()} returns the frame at the top of the call stack; |
| 586 | if the optional integer argument \var{depth} is supplied, the function returns the frame |
| 587 | that is \var{depth} calls below the top of the stack. For example, \code{sys._getframe(1)} |
| 588 | returns the caller's frame object. |
| 589 | |
| 590 | This function is only present in CPython, not in Jython or the .NET |
| 591 | implementation. Use it for debugging, and resist the temptation to |
| 592 | put it into production code. |
| 593 | |
| 594 | |
Andrew M. Kuchling | 81b6ae7 | 2001-02-11 16:55:39 +0000 | [diff] [blame] | 595 | |
| 596 | \end{itemize} |
| 597 | |
| 598 | %====================================================================== |
Andrew M. Kuchling | 74d18ed | 2001-02-28 22:22:40 +0000 | [diff] [blame] | 599 | \section{Other Changes and Fixes} |
Andrew M. Kuchling | 90cecee | 2001-01-22 04:02:09 +0000 | [diff] [blame] | 600 | |
| 601 | There were relatively few smaller changes made in Python 2.1 due to |
| 602 | the shorter release cycle. A search through the CVS change logs turns |
| 603 | up 57 patches applied, and 86 bugs fixed; both figures are likely to |
| 604 | be underestimates. Some of the more notable changes are: |
| 605 | |
| 606 | \begin{itemize} |
| 607 | |
Andrew M. Kuchling | bf14014 | 2001-02-28 22:10:07 +0000 | [diff] [blame] | 608 | |
| 609 | \item A specialized object allocator is now optionally available, that |
| 610 | should be faster than the system \function{malloc()} and have less |
| 611 | memory overhead. The allocator uses C's \function{malloc()} function |
| 612 | to get large pools of memory, and then fulfills smaller memory |
| 613 | requests from these pools. It can be enabled by providing the |
Andrew M. Kuchling | 694e181 | 2001-03-01 01:02:52 +0000 | [diff] [blame^] | 614 | \longprogramopt{--with-pymalloc} option to the \program{configure} script; see |
Andrew M. Kuchling | 74d18ed | 2001-02-28 22:22:40 +0000 | [diff] [blame] | 615 | \file{Objects/obmalloc.c} for the implementation details. |
Andrew M. Kuchling | bf14014 | 2001-02-28 22:10:07 +0000 | [diff] [blame] | 616 | Contributed by Vladimir Marangozov. |
| 617 | |
Andrew M. Kuchling | 90cecee | 2001-01-22 04:02:09 +0000 | [diff] [blame] | 618 | \item The speed of line-oriented file I/O has been improved because |
| 619 | people often complain about its lack of speed, and because it's often |
| 620 | been used as a na\"ive benchmark. The \method{readline()} method of |
| 621 | file objects has therefore been rewritten to be much faster. The |
| 622 | exact amount of the speedup will vary from platform to platform |
| 623 | depending on how slow the C library's \function{getc()} was, but is |
| 624 | around 66\%, and potentially much faster on some particular operating |
Andrew M. Kuchling | f228fd1 | 2001-01-22 17:52:19 +0000 | [diff] [blame] | 625 | systems. Tim Peters did much of the benchmarking and coding for this |
| 626 | change, motivated by a discussion in comp.lang.python. |
Andrew M. Kuchling | 90cecee | 2001-01-22 04:02:09 +0000 | [diff] [blame] | 627 | |
| 628 | A new module and method for file objects was also added, contributed |
| 629 | by Jeff Epler. The new method, \method{xreadlines()}, is similar to |
| 630 | the existing \function{xrange()} built-in. \function{xreadlines()} |
| 631 | returns an opaque sequence object that only supports being iterated |
Andrew M. Kuchling | f228fd1 | 2001-01-22 17:52:19 +0000 | [diff] [blame] | 632 | over, reading a line on every iteration but not reading the entire |
Andrew M. Kuchling | f33c118 | 2001-01-23 02:48:26 +0000 | [diff] [blame] | 633 | file into memory as the existing \method{readlines()} method does. |
| 634 | You'd use it like this: |
Andrew M. Kuchling | 90cecee | 2001-01-22 04:02:09 +0000 | [diff] [blame] | 635 | |
| 636 | \begin{verbatim} |
| 637 | for line in sys.stdin.xreadlines(): |
| 638 | # ... do something for each line ... |
| 639 | ... |
| 640 | \end{verbatim} |
| 641 | |
Andrew M. Kuchling | f228fd1 | 2001-01-22 17:52:19 +0000 | [diff] [blame] | 642 | For a fuller discussion of the line I/O changes, see the python-dev |
Andrew M. Kuchling | 6a360bd | 2001-02-05 02:47:52 +0000 | [diff] [blame] | 643 | summary for January 1-15, 2001. |
Andrew M. Kuchling | 91834c6 | 2001-01-22 19:51:13 +0000 | [diff] [blame] | 644 | |
Andrew M. Kuchling | 6a360bd | 2001-02-05 02:47:52 +0000 | [diff] [blame] | 645 | \item A new method, \method{popitem()}, was added to dictionaries to |
| 646 | enable destructively iterating through the contents of a dictionary; |
| 647 | this can be faster for large dictionaries because . |
| 648 | \code{D.popitem()} removes a random \code{(\var{key}, \var{value})} |
| 649 | pair from the dictionary and returns it as a 2-tuple. This was |
| 650 | implemented mostly by Tim Peters and Guido van Rossum, after a |
| 651 | suggestion and preliminary patch by Moshe Zadka. |
Andrew M. Kuchling | 90cecee | 2001-01-22 04:02:09 +0000 | [diff] [blame] | 652 | |
Andrew M. Kuchling | 90cecee | 2001-01-22 04:02:09 +0000 | [diff] [blame] | 653 | \item Modules can now control which names are imported when \code{from |
Andrew M. Kuchling | 6a360bd | 2001-02-05 02:47:52 +0000 | [diff] [blame] | 654 | \var{module} import *} is used, by defining an \code{__all__} |
| 655 | attribute containing a list of names that will be imported. One |
| 656 | common complaint is that if the module imports other modules such as |
Andrew M. Kuchling | 90cecee | 2001-01-22 04:02:09 +0000 | [diff] [blame] | 657 | \module{sys} or \module{string}, \code{from \var{module} import *} |
| 658 | will add them to the importing module's namespace. To fix this, |
| 659 | simply list the public names in \code{__all__}: |
| 660 | |
| 661 | \begin{verbatim} |
| 662 | # List public names |
| 663 | __all__ = ['Database', 'open'] |
| 664 | \end{verbatim} |
| 665 | |
Andrew M. Kuchling | b216ab6 | 2001-01-22 16:15:44 +0000 | [diff] [blame] | 666 | A stricter version of this patch was first suggested and implemented |
Andrew M. Kuchling | 6a360bd | 2001-02-05 02:47:52 +0000 | [diff] [blame] | 667 | by Ben Wolfson, but after some python-dev discussion, a weaker final |
| 668 | version was checked in. |
Andrew M. Kuchling | b216ab6 | 2001-01-22 16:15:44 +0000 | [diff] [blame] | 669 | |
Andrew M. Kuchling | 6a360bd | 2001-02-05 02:47:52 +0000 | [diff] [blame] | 670 | \item Applying \function{repr()} to strings previously used octal |
| 671 | escapes for non-printable characters; for example, a newline was |
| 672 | \code{'\e 012'}. This was a vestigial trace of Python's C ancestry, but |
| 673 | today octal is of very little practical use. Ka-Ping Yee suggested |
| 674 | using hex escapes instead of octal ones, and using the \code{\e n}, |
| 675 | \code{\e t}, \code{\e r} escapes for the appropriate characters, and |
| 676 | implemented this new formatting. |
Andrew M. Kuchling | 4308d3c | 2001-01-29 17:36:53 +0000 | [diff] [blame] | 677 | |
Andrew M. Kuchling | 6a360bd | 2001-02-05 02:47:52 +0000 | [diff] [blame] | 678 | \item Syntax errors detected at compile-time can now raise exceptions |
| 679 | containing the filename and line number of the error, a pleasant side |
| 680 | effect of the compiler reorganization done by Jeremy Hylton. |
| 681 | |
Andrew M. Kuchling | 15ad28c | 2001-02-14 02:44:18 +0000 | [diff] [blame] | 682 | \item C extensions which import other modules have been changed to use |
| 683 | \function{PyImport_ImportModule()}, which means that they will use any |
| 684 | import hooks that have been installed. This is also encouraged for |
| 685 | third-party extensions that need to import some other module from C |
| 686 | code. |
| 687 | |
Andrew M. Kuchling | 6a360bd | 2001-02-05 02:47:52 +0000 | [diff] [blame] | 688 | \item The size of the Unicode character database was shrunk by another |
| 689 | 340K thanks to Fredrik Lundh. |
Andrew M. Kuchling | 91834c6 | 2001-01-22 19:51:13 +0000 | [diff] [blame] | 690 | |
Andrew M. Kuchling | 90cecee | 2001-01-22 04:02:09 +0000 | [diff] [blame] | 691 | \end{itemize} |
| 692 | |
Andrew M. Kuchling | 74d18ed | 2001-02-28 22:22:40 +0000 | [diff] [blame] | 693 | And there's the usual list of minor bugfixes, minor memory leaks, |
| 694 | docstring edits, and other tweaks, too lengthy to be worth itemizing; |
| 695 | see the CVS logs for the full details if you want them. |
Andrew M. Kuchling | 90cecee | 2001-01-22 04:02:09 +0000 | [diff] [blame] | 696 | |
| 697 | |
Andrew M. Kuchling | 6a360bd | 2001-02-05 02:47:52 +0000 | [diff] [blame] | 698 | %====================================================================== |
Andrew M. Kuchling | 90cecee | 2001-01-22 04:02:09 +0000 | [diff] [blame] | 699 | \section{Acknowledgements} |
| 700 | |
Andrew M. Kuchling | 6a360bd | 2001-02-05 02:47:52 +0000 | [diff] [blame] | 701 | The author would like to thank the following people for offering |
| 702 | suggestions on various drafts of this article: Graeme Cross, David |
| 703 | Goodger, Jay Graves, Michael Hudson, Marc-Andr\'e Lemburg, Fredrik |
| 704 | Lundh, Neil Schemenauer, Thomas Wouters. |
Andrew M. Kuchling | 90cecee | 2001-01-22 04:02:09 +0000 | [diff] [blame] | 705 | |
| 706 | \end{document} |