簡介¶

This article explains the new features in Python 2.1. While there aren't asmany changes in 2.1 as there were in Python 2.0, there are still some pleasantsurprises in store. 2.1 is the first release to be steered through the use ofPython Enhancement Proposals, or PEPs, so most of the sizable changes haveaccompanying PEPs that provide more complete documentation and a designrationale for the change. This article doesn't attempt to document the newfeatures completely, but simply provides an overview of the new features forPython programmers. Refer to the Python 2.1 documentation, or to the specificPEP, for more details about any new feature that particularly interests you.

One recent goal of the Python development team has been to accelerate the paceof new releases, with a new release coming every 6 to 9 months. 2.1 is the firstrelease to come out at this faster pace, with the first alpha appearing inJanuary, 3 months after the final version of 2.0 was released.

The final release of Python 2.1 was made on April 17, 2001.

PEP 227: Nested Scopes¶

The largest change in Python 2.1 is to Python's scoping rules. In Python 2.0,at any given time there are at most three namespaces used to look up variablenames: local, module-level, and the built-in namespace. This often surprisedpeople because it didn't match their intuitive expectations. For example, anested recursive function definition doesn't work:

deff():...defg(value):...returng(value-1)+1...

The functiong() will always raise aNameError exception, becausethe binding of the nameg isn't in either its local namespace or in themodule-level namespace. This isn't much of a problem in practice (how often doyou recursively define interior functions like this?), but this also made usingthelambda expression clumsier, and this was a problem in practice.In code which useslambda you can often find local variables beingcopied by passing them as the default values of arguments.

deffind(self,name):"Return list of any entries equal to 'name'"L=filter(lambdax,name=name:x==name,self.list_attribute)returnL

The readability of Python code written in a strongly functional style suffersgreatly as a result.

The most significant change to Python 2.1 is that static scoping has been addedto the language to fix this problem. As a first effect, thename=namedefault argument is now unnecessary in the above example. Put simply, when agiven variable name is not assigned a value within a function (by an assignment,or thedef,class, orimport statements),references to the variable will be looked up in the local namespace of theenclosing scope. A more detailed explanation of the rules, and a dissection ofthe implementation, can be found in the PEP.

This change may cause some compatibility problems for code where the samevariable name is used both at the module level and as a local variable within afunction that contains further function definitions. This seems rather unlikelythough, since such code would have been pretty confusing to read in the firstplace.

One side effect of the change is that thefrommoduleimport* andexec statements have been made illegal inside a function scope undercertain conditions. The Python reference manual has said all along thatfrommoduleimport* is only legal at the top level of a module, but the CPythoninterpreter has never enforced this before. As part of the implementation ofnested scopes, the compiler which turns Python source into bytecodes has togenerate different code to access variables in a containing scope.frommoduleimport* andexec make it impossible for the compiler tofigure this out, because they add names to the local namespace that areunknowable at compile time. Therefore, if a function contains functiondefinitions orlambda expressions with free variables, the compilerwill flag this by raising aSyntaxError exception.

To make the preceding explanation a bit clearer, here's an example:

x=1deff():# The next line is a syntax errorexec'x=2'defg():returnx

Line 4 containing theexec statement is a syntax error, sinceexec would define a new local variable namedx whose value shouldbe accessed byg().

This shouldn't be much of a limitation, sinceexec is rarely used inmost Python code (and when it is used, it's often a sign of a poor designanyway).

Compatibility concerns have led to nested scopes being introduced gradually; inPython 2.1, they aren't enabled by default, but can be turned on within a moduleby using a future statement as described inPEP 236. (See the following sectionfor further discussion ofPEP 236.) In Python 2.2, nested scopes will becomethe default and there will be no way to turn them off, but users will have hadall of 2.1's lifetime to fix any breakage resulting from their introduction.

PEP 236: __future__ Directives¶

The reaction to nested scopes was widespread concern about the dangers ofbreaking code with the 2.1 release, and it was strong enough to make thePythoneers take a more conservative approach. This approach consists ofintroducing a convention for enabling optional functionality in release N thatwill become compulsory in release N+1.

The syntax uses afrom...import statement using the reserved module name__future__. Nested scopes can be enabled by the following statement:

from__future__importnested_scopes

While it looks like a normalimport statement, it's not; there arestrict rules on where such a future statement can be put. They can only be atthe top of a module, and must precede any Python code or regularimport statements. This is because such statements can affect howthe Python bytecode compiler parses code and generates bytecode, so they mustprecede any statement that will result in bytecodes being produced.

PEP 207: Rich Comparisons¶

In earlier versions, Python's support for implementing comparisons on user-definedclasses and extension types was quite simple. Classes could implement a__cmp__() method that was given two instances of a class, and could onlyreturn 0 if they were equal or +1 or -1 if they weren't; the method couldn'traise an exception or return anything other than a Boolean value. Users ofNumeric Python often found this model too weak and restrictive, because in thenumber-crunching programs that numeric Python is used for, it would be moreuseful to be able to perform elementwise comparisons of two matrices, returninga matrix containing the results of a given comparison for each element. If thetwo matrices are of different sizes, then the compare has to be able to raise anexception to signal the error.

In Python 2.1, rich comparisons were added in order to support this need.Python classes can now individually overload each of the<,<=,>,>=,==, and!= operations. The new magic method names are:

(The magic methods are named after the corresponding Fortran operators.LT...LE., &c. Numeric programmers are almost certainly quite familiar withthese names and will find them easy to remember.)

Each of these magic methods is of the formmethod(self,other), whereself will be the object on the left-hand side of the operator, whileother will be the object on the right-hand side. For example, theexpressionA<B will causeA.__lt__(B) to be called.

Each of these magic methods can return anything at all: a Boolean, a matrix, alist, or any other Python object. Alternatively they can raise an exception ifthe comparison is impossible, inconsistent, or otherwise meaningless.

The built-incmp(A,B) function can use the rich comparison machinery,and now accepts an optional argument specifying which comparison operation touse; this is given as one of the strings"<","<=",">",">=","==", or"!=". If called without the optional third argument,cmp() will only return -1, 0, or +1 as in previous versions of Python;otherwise it will call the appropriate method and can return any Python object.

There are also corresponding changes of interest to C programmers; there's a newslottp_richcmp in type objects and an API for performing a given richcomparison. I won't cover the C API here, but will refer you toPEP 207, or to2.1's C API documentation, for the full list of related functions.

PEP 230: Warning Framework¶

Over its 10 years of existence, Python has accumulated a certain number ofobsolete modules and features along the way. It's difficult to know when afeature is safe to remove, since there's no way of knowing how much code uses it--- perhaps no programs depend on the feature, or perhaps many do. To enableremoving old features in a more structured way, a warning framework was added.When the Python developers want to get rid of a feature, it will first trigger awarning in the next version of Python. The following Python version can thendrop the feature, and users will have had a full release cycle to remove uses ofthe old feature.

Python 2.1 adds the warning framework to be used in this scheme. It adds awarnings module that provide functions to issue warnings, and to filterout warnings that you don't want to be displayed. Third-party modules can alsouse this framework to deprecate old features that they no longer wish tosupport.

For example, in Python 2.1 theregex module is deprecated, so importingit causes a warning to be printed:

>>>importregex__main__:1: DeprecationWarning: the regex module         is deprecated; please use the re module>>>

Warnings can be issued by calling thewarnings.warn() function:

warnings.warn("feature X no longer supported")

The first parameter is the warning message; an additional optional parameterscan be used to specify a particular warning category.

Filters can be added to disable certain warnings; a regular expression patterncan be applied to the message or to the module name in order to suppress awarning. For example, you may have a program that uses theregex moduleand not want to spare the time to convert it to use there module rightnow. The warning can be suppressed by calling

importwarningswarnings.filterwarnings(action='ignore',message='.*regex module is deprecated',category=DeprecationWarning,module='__main__')

This adds a filter that will apply only to warnings of the classDeprecationWarning triggered in the__main__ module, and appliesa regular expression to only match the message about theregex modulebeing deprecated, and will cause such warnings to be ignored. Warnings can alsobe printed only once, printed every time the offending code is executed, orturned into exceptions that will cause the program to stop (unless theexceptions are caught in the usual way, of course).

Functions were also added to Python's C API for issuing warnings; refer to PEP230 or to Python's API documentation for the details.

PEP 229: New Build System¶

When compiling Python, the user had to go in and edit theModules/Setupfile in order to enable various additional modules; the default set isrelatively small and limited to modules that compile on most Unix platforms.This means that on Unix platforms with many more features, most notably Linux,Python installations often don't contain all useful modules they could.

Python 2.0 added the Distutils, a set of modules for distributing and installingextensions. In Python 2.1, the Distutils are used to compile much of thestandard library of extension modules, autodetecting which ones are supported onthe current machine. It's hoped that this will make Python installations easierand more featureful.

Instead of having to edit theModules/Setup file in order to enablemodules, asetup.py script in the top directory of the Python sourcedistribution is run at build time, and attempts to discover which modules can beenabled by examining the modules and header files on the system. If a module isconfigured inModules/Setup, thesetup.py script won't attemptto compile that module and will defer to theModules/Setup file'scontents. This provides a way to specific any strange command-line flags orlibraries that are required for a specific platform.

In another far-reaching change to the build mechanism, Neil Schemenauerrestructured things so Python now uses a single makefile that isn't recursive,instead of makefiles in the top directory and in each of thePython/,Parser/,Objects/, andModules/ subdirectories. Thismakes building Python faster and also makes hacking the Makefiles clearer andsimpler.

PEP 205: Weak References¶

Weak references, available through theweakref module, are a minor butuseful new data type in the Python programmer's toolbox.

Storing a reference to an object (say, in a dictionary or a list) has the sideeffect of keeping that object alive forever. There are a few specific caseswhere this behaviour is undesirable, object caches being the most common one,and another being circular references in data structures such as trees.

For example, consider a memoizing function that caches the results of anotherfunctionf(x) by storing the function's argument and its result in adictionary:

_cache={}defmemoize(x):if_cache.has_key(x):return_cache[x]retval=f(x)# Cache the returned object_cache[x]=retvalreturnretval

This version works for simple things such as integers, but it has a side effect;the_cache dictionary holds a reference to the return values, so they'llnever be deallocated until the Python process exits and cleans up. This isn'tvery noticeable for integers, but iff() returns an object, or a datastructure that takes up a lot of memory, this can be a problem.

Weak references provide a way to implement a cache that won't keep objects alivebeyond their time. If an object is only accessible through weak references, theobject will be deallocated and the weak references will now indicate that theobject it referred to no longer exists. A weak reference to an objectobj iscreated by callingwr=weakref.ref(obj). The object being referred to isreturned by calling the weak reference as if it were a function:wr(). Itwill return the referenced object, orNone if the object no longer exists.

This makes it possible to write amemoize() function whose cache doesn'tkeep objects alive, by storing weak references in the cache.

_cache={}defmemoize(x):if_cache.has_key(x):obj=_cache[x]()# If weak reference object still exists,# return itifobjisnotNone:returnobjretval=f(x)# Cache a weak reference_cache[x]=weakref.ref(retval)returnretval

Theweakref module also allows creating proxy objects which behave likeweak references --- an object referenced only by proxy objects is deallocated --but instead of requiring an explicit call to retrieve the object, the proxytransparently forwards all operations to the object as long as the object stillexists. If the object is deallocated, attempting to use a proxy will cause aweakref.ReferenceError exception to be raised.

proxy=weakref.proxy(obj)proxy.attr# Equivalent to obj.attrproxy.meth()# Equivalent to obj.meth()delobjproxy.attr# raises weakref.ReferenceError

PEP 232: Function Attributes¶

In Python 2.1, functions can now have arbitrary information attached to them.People were often using docstrings to hold information about functions andmethods, because the__doc__ attribute was the only way ofattaching anyinformation to a function. For example, in the Zope web application server,functions are marked as safe for public access by having a docstring, and inJohn Aycock's SPARK parsing framework, docstrings hold parts of the BNF grammarto be parsed. This overloading is unfortunate, since docstrings are reallyintended to hold a function's documentation; for example, it means you can'tproperly document functions intended for private use in Zope.

Arbitrary attributes can now be set and retrieved on functions using the regularPython syntax:

deff():passf.publish=1f.secure=1f.grammar="A ::= B (C D)*"

The dictionary containing attributes can be accessed as the function's__dict__. Unlike the__dict__ attribute of class instances, infunctions you can actually assign a new dictionary to__dict__, thoughthe new value is restricted to a regular Python dictionary; youcan't betricky and set it to aUserDict instance, or any other random objectthat behaves like a mapping.

PEP 235: Importing Modules on Case-Insensitive Platforms¶

Some operating systems have filesystems that are case-insensitive, MacOS andWindows being the primary examples; on these systems, it's impossible todistinguish the filenamesFILE.PY andfile.py, even though they do storethe file's name in its original case (they're case-preserving, too).

In Python 2.1, theimport statement will work to simulate case-sensitivityon case-insensitive platforms. Python will now search for the firstcase-sensitive match by default, raising anImportError if no such fileis found, soimportfile will not import a module namedFILE.PY.Case-insensitive matching can be requested by setting thePYTHONCASEOKenvironment variable before starting the Python interpreter.

PEP 217: Interactive Display Hook¶

When using the Python interpreter interactively, the output of commands isdisplayed using the built-inrepr() function. In Python 2.1, the variablesys.displayhook() can be set to a callable object which will be calledinstead ofrepr(). For example, you can set it to a specialpretty-printing function:

>>># Create a recursive data structure...L=[1,2,3]>>>L.append(L)>>>L# Show Python's default output[1, 2, 3, [...]]>>># Use pprint.pprint() as the display function...importsys,pprint>>>sys.displayhook=pprint.pprint>>>L[1, 2, 3,  <Recursion on list with id=135143996>]>>>

PEP 208: New Coercion Model¶

How numeric coercion is done at the C level was significantly modified. Thiswill only affect the authors of C extensions to Python, allowing them moreflexibility in writing extension types that support numeric operations.

Extension types can now set the type flagPy_TPFLAGS_CHECKTYPES in theirPyTypeObject structure to indicate that they support the new coercion model.In such extension types, the numeric slot functions can no longer assume thatthey'll be passed two arguments of the same type; instead they may be passed twoarguments of differing types, and can then perform their own internal coercion.If the slot function is passed a type it can't handle, it can indicate thefailure by returning a reference to thePy_NotImplemented singleton value.The numeric functions of the other type will then be tried, and perhaps they canhandle the operation; if the other type also returnsPy_NotImplemented, thenaTypeError will be raised. Numeric methods written in Python can alsoreturnPy_NotImplemented, causing the interpreter to act as if the methoddid not exist (perhaps raising aTypeError, perhaps trying anotherobject's numeric methods).

PEP 241: Metadata in Python Packages¶

A common complaint from Python users is that there's no single catalog of allthe Python modules in existence. T. Middleton's Vaults of Parnassus atwww.vex.net/parnassus/ (retired in February 2009,available in theInternet Archive Wayback Machine)was the largest catalog of Python modules, butregistering software at the Vaults is optional, and many people did not bother.

As a first small step toward fixing the problem, Python software packaged usingthe Distutilssdist command will include a file namedPKG-INFO containing information about the package such as its name,version, and author (metadata, in cataloguing terminology).PEP 241 containsthe full list of fields that can be present in thePKG-INFO file. Aspeople began to package their software using Python 2.1, more and more packageswill include metadata, making it possible to build automated cataloguing systemsand experiment with them. With the result experience, perhaps it'll be possibleto design a really good catalog and then build support for it into Python 2.2.For example, the Distutilssdist andbdist_* commandscould support anupload option that would automatically upload yourpackage to a catalog server.

You can start creating packages containingPKG-INFO even if you're notusing Python 2.1, since a new release of the Distutils will be made for users ofearlier Python versions. Version 1.0.2 of the Distutils includes the changesdescribed inPEP 241, as well as various bugfixes and enhancements. It will beavailable from the Distutils SIG athttps://www.python.org/community/sigs/current/distutils-sig/.

New and Improved Modules¶

• Ka-Ping Yee contributed two new modules:inspect.py, a module forgetting information about live Python code, andpydoc.py, a module forinteractively converting docstrings to HTML or text. As a bonus,Tools/scripts/pydoc, which is now automatically installed, usespydoc.py to display documentation given a Python module, package, orclass name. For example,pydocxml.dom displays the following:

  PythonLibraryDocumentation:packagexml.dominxmlNAMExml.dom-W3CDocumentObjectModelimplementationforPython.FILE/usr/local/lib/python2.1/xml/dom/__init__.pycDESCRIPTIONThePythonmappingoftheDocumentObjectModelisdocumentedinthePythonLibraryReferenceinthesectiononthexml.dompackage.Thispackagecontainsthefollowingmodules:...

  pydoc also includes a Tk-based interactive help browser.pydocquickly becomes addictive; try it out!

• Two different modules for unit testing were added to the standard library.Thedoctest module, contributed by Tim Peters, provides a testingframework based on running embedded examples in docstrings and comparing theresults against the expected output. PyUnit, contributed by Steve Purcell, is aunit testing framework inspired by JUnit, which was in turn an adaptation ofKent Beck's Smalltalk testing framework. Seehttps://pyunit.sourceforge.net/ formore information about PyUnit.

• Thedifflib module contains a class,SequenceMatcher, whichcompares two sequences and computes the changes required to transform onesequence into the other. For example, this module can be used to write a toolsimilar to the Unixdiff program, and in fact the sample programTools/scripts/ndiff.py demonstrates how to write such a script.

• curses.panel, a wrapper for the panel library, part of ncurses and ofSYSV curses, was contributed by Thomas Gellekum. The panel library provideswindows with the additional feature of depth. Windows can be moved higher orlower in the depth ordering, and the panel library figures out where panelsoverlap and which sections are visible.

• The PyXML package has gone through a few releases since Python 2.0, and Python2.1 includes an updated version of thexml package. Some of thenoteworthy changes include support for Expat 1.2 and later versions, the abilityfor Expat parsers to handle files in any encoding supported by Python, andvarious bugfixes for SAX, DOM, and theminidom module.

• Ping also contributed another hook for handling uncaught exceptions.sys.excepthook() can be set to a callable object. When an exception isn'tcaught by anytry...except blocks, the exception will bepassed tosys.excepthook(), which can then do whatever it likes. At theNinth Python Conference, Ping demonstrated an application for this hook:printing an extended traceback that not only lists the stack frames, but alsolists the function arguments and the local variables for each frame.

• Various functions in thetime module, such asasctime() andlocaltime(), require a floating-point argument containing the time inseconds since the epoch. The most common use of these functions is to work withthe current time, so the floating-point argument has been made optional; when avalue isn't provided, the current time will be used. For example, log fileentries usually need a string containing the current time; in Python 2.1,time.asctime() can be used, instead of the lengthiertime.asctime(time.localtime(time.time())) that was previously required.

  This change was proposed and implemented by Thomas Wouters.

• Theftplib module now defaults to retrieving files in passive mode,because passive mode is more likely to work from behind a firewall. Thisrequest came from the Debian bug tracking system, since other Debian packagesuseftplib to retrieve files and then don't work from behind a firewall.It's deemed unlikely that this will cause problems for anyone, because Netscapedefaults to passive mode and few people complain, but if passive mode isunsuitable for your application or network setup, callset_pasv(0) onFTP objects to disable passive mode.

• Support for raw socket access has been added to thesocket module,contributed by Grant Edwards.

• Thepstats module now contains a simple interactive statistics browserfor displaying timing profiles for Python programs, invoked when the module isrun as a script. Contributed by Eric S. Raymond.

• A new implementation-dependent function,sys._getframe([depth]), hasbeen added to return a given frame object from the current call stack.sys._getframe() returns the frame at the top of the call stack; if theoptional integer argumentdepth is supplied, the function returns the framethat isdepth calls below the top of the stack. For example,sys._getframe(1) returns the caller's frame object.

  This function is only present in CPython, not in Jython or the .NETimplementation. Use it for debugging, and resist the temptation to put it intoproduction code.

Other Changes and Fixes¶

There were relatively few smaller changes made in Python 2.1 due to the shorterrelease cycle. A search through the CVS change logs turns up 117 patchesapplied, and 136 bugs fixed; both figures are likely to be underestimates. Someof the more notable changes are:

• A specialized object allocator is now optionally available, that should befaster than the systemmalloc() and have less memory overhead. Theallocator uses C'smalloc() function to get large pools of memory, andthen fulfills smaller memory requests from these pools. It can be enabled byproviding the--with-pymalloc option to theconfigurescript; seeObjects/obmalloc.c for the implementation details.

  Authors of C extension modules should test their code with the object allocatorenabled, because some incorrect code may break, causing core dumps at runtime.There are a bunch of memory allocation functions in Python's C API that havepreviously been just aliases for the C library'smalloc() andfree(), meaning that if you accidentally called mismatched functions, theerror wouldn't be noticeable. When the object allocator is enabled, thesefunctions aren't aliases ofmalloc() andfree() any more, andcalling the wrong function to free memory will get you a core dump. Forexample, if memory was allocated usingPyMem_New, it has to be freedusingPyMem_Del(), notfree(). A few modules included with Pythonfell afoul of this and had to be fixed; doubtless there are more third-partymodules that will have the same problem.

  The object allocator was contributed by Vladimir Marangozov.

• The speed of line-oriented file I/O has been improved because people oftencomplain about its lack of speed, and because it's often been used as a naïvebenchmark. Thereadline() method of file objects has therefore beenrewritten to be much faster. The exact amount of the speedup will vary fromplatform to platform depending on how slow the C library'sgetc() was, butis around 66%, and potentially much faster on some particular operating systems.Tim Peters did much of the benchmarking and coding for this change, motivated bya discussion in comp.lang.python.

  A new module and method for file objects was also added, contributed by JeffEpler. The new method,xreadlines(), is similar to the existingxrange() built-in.xreadlines() returns an opaque sequence objectthat only supports being iterated over, reading a line on every iteration butnot reading the entire file into memory as the existingreadlines() methoddoes. You'd use it like this:

  forlineinsys.stdin.xreadlines():# ... do something for each line ......

  For a fuller discussion of the line I/O changes, see the python-dev summary forJanuary 1--15, 2001 athttps://mail.python.org/pipermail/python-dev/2001-January/.

• A new method,popitem(), was added to dictionaries to enabledestructively iterating through the contents of a dictionary; this can be fasterfor large dictionaries because there's no need to construct a list containingall the keys or values.D.popitem() removes a random(key,value) pairfrom the dictionaryD and returns it as a 2-tuple. This was implementedmostly by Tim Peters and Guido van Rossum, after a suggestion and preliminarypatch by Moshe Zadka.

• Modules can now control which names are imported whenfrommoduleimport*is used, by defining an__all__ attribute containing a list of names thatwill be imported. One common complaint is that if the module imports othermodules such assys orstring,frommoduleimport* will addthem to the importing module's namespace. To fix this, simply list the publicnames in__all__:

  # List public names__all__=['Database','open']

  A stricter version of this patch was first suggested and implemented by BenWolfson, but after some python-dev discussion, a weaker final version waschecked in.

• Applyingrepr() to strings previously used octal escapes fornon-printable characters; for example, a newline was'\012'. This was avestigial trace of Python's C ancestry, but today octal is of very littlepractical use. Ka-Ping Yee suggested using hex escapes instead of octal ones,and using the\n,\t,\r escapes for the appropriate characters,and implemented this new formatting.

• Syntax errors detected at compile-time can now raise exceptions containing thefilename and line number of the error, a pleasant side effect of the compilerreorganization done by Jeremy Hylton.

• C extensions which import other modules have been changed to usePyImport_ImportModule(), which means that they will use any import hooksthat have been installed. This is also encouraged for third-party extensionsthat need to import some other module from C code.

• The size of the Unicode character database was shrunk by another 340K thanksto Fredrik Lundh.

• Some new ports were contributed: MacOS X (by Steven Majewski), Cygwin (byJason Tishler); RISCOS (by Dietmar Schwertberger); Unixware 7 (by Billy G.Allie).

And there's the usual list of minor bugfixes, minor memory leaks, docstringedits, and other tweaks, too lengthy to be worth itemizing; see the CVS logs forthe full details if you want them.

致謝¶

The author would like to thank the following people for offering suggestions onvarious drafts of this article: Graeme Cross, David Goodger, Jay Graves, MichaelHudson, Marc-André Lemburg, Fredrik Lundh, Neil Schemenauer, Thomas Wouters.