mirror of
				https://github.com/bunny-lab-io/Borealis.git
				synced 2025-10-27 07:21:58 -06:00 
			
		
		
		
	
		
			
				
	
	
		
			1068 lines
		
	
	
		
			88 KiB
		
	
	
	
		
			HTML
		
	
	
	
	
	
			
		
		
	
	
			1068 lines
		
	
	
		
			88 KiB
		
	
	
	
		
			HTML
		
	
	
	
	
	
| <!DOCTYPE html>
 | ||
| 
 | ||
| <html lang="en" data-content_root="../">
 | ||
|   <head>
 | ||
|     <meta charset="utf-8" />
 | ||
|     <meta name="viewport" content="width=device-width, initial-scale=1.0" /><meta name="viewport" content="width=device-width, initial-scale=1" />
 | ||
| <meta property="og:title" content="What’s New in Python 2.1" />
 | ||
| <meta property="og:type" content="website" />
 | ||
| <meta property="og:url" content="https://docs.python.org/3/whatsnew/2.1.html" />
 | ||
| <meta property="og:site_name" content="Python documentation" />
 | ||
| <meta property="og:description" content="Author, A.M. Kuchling,. Introduction: This article explains the new features in Python 2.1. While there aren’t as many changes in 2.1 as there were in Python 2.0, there are still some pleasant surp..." />
 | ||
| <meta property="og:image" content="https://docs.python.org/3/_static/og-image.png" />
 | ||
| <meta property="og:image:alt" content="Python documentation" />
 | ||
| <meta name="description" content="Author, A.M. Kuchling,. Introduction: This article explains the new features in Python 2.1. While there aren’t as many changes in 2.1 as there were in Python 2.0, there are still some pleasant surp..." />
 | ||
| <meta property="og:image:width" content="200">
 | ||
| <meta property="og:image:height" content="200">
 | ||
| <meta name="theme-color" content="#3776ab">
 | ||
| 
 | ||
|     <title>What’s New in Python 2.1 — Python 3.13.3 documentation</title><meta name="viewport" content="width=device-width, initial-scale=1.0">
 | ||
|     
 | ||
|     <link rel="stylesheet" type="text/css" href="../_static/pygments.css?v=b86133f3" />
 | ||
|     <link rel="stylesheet" type="text/css" href="../_static/pydoctheme.css?v=23252803" />
 | ||
|     <link id="pygments_dark_css" media="(prefers-color-scheme: dark)" rel="stylesheet" type="text/css" href="../_static/pygments_dark.css?v=5349f25f" />
 | ||
|     
 | ||
|     <script src="../_static/documentation_options.js?v=5d57ca2d"></script>
 | ||
|     <script src="../_static/doctools.js?v=9bcbadda"></script>
 | ||
|     <script src="../_static/sphinx_highlight.js?v=dc90522c"></script>
 | ||
|     
 | ||
|     <script src="../_static/sidebar.js"></script>
 | ||
|     
 | ||
|     <link rel="search" type="application/opensearchdescription+xml"
 | ||
|           title="Search within Python 3.13.3 documentation"
 | ||
|           href="../_static/opensearch.xml"/>
 | ||
|     <link rel="author" title="About these documents" href="../about.html" />
 | ||
|     <link rel="index" title="Index" href="../genindex.html" />
 | ||
|     <link rel="search" title="Search" href="../search.html" />
 | ||
|     <link rel="copyright" title="Copyright" href="../copyright.html" />
 | ||
|     <link rel="next" title="What’s New in Python 2.0" href="2.0.html" />
 | ||
|     <link rel="prev" title="What’s New in Python 2.2" href="2.2.html" />
 | ||
|     
 | ||
|     <link rel="canonical" href="https://docs.python.org/3/whatsnew/2.1.html">
 | ||
|     
 | ||
|       
 | ||
|     
 | ||
| 
 | ||
|     
 | ||
|     <style>
 | ||
|       @media only screen {
 | ||
|         table.full-width-table {
 | ||
|             width: 100%;
 | ||
|         }
 | ||
|       }
 | ||
|     </style>
 | ||
| <link rel="stylesheet" href="../_static/pydoctheme_dark.css" media="(prefers-color-scheme: dark)" id="pydoctheme_dark_css">
 | ||
|     <link rel="shortcut icon" type="image/png" href="../_static/py.svg" />
 | ||
|             <script type="text/javascript" src="../_static/copybutton.js"></script>
 | ||
|             <script type="text/javascript" src="../_static/menu.js"></script>
 | ||
|             <script type="text/javascript" src="../_static/search-focus.js"></script>
 | ||
|             <script type="text/javascript" src="../_static/themetoggle.js"></script> 
 | ||
|             <script type="text/javascript" src="../_static/rtd_switcher.js"></script>
 | ||
|             <meta name="readthedocs-addons-api-version" content="1">
 | ||
| 
 | ||
|   </head>
 | ||
| <body>
 | ||
| <div class="mobile-nav">
 | ||
|     <input type="checkbox" id="menuToggler" class="toggler__input" aria-controls="navigation"
 | ||
|            aria-pressed="false" aria-expanded="false" role="button" aria-label="Menu" />
 | ||
|     <nav class="nav-content" role="navigation">
 | ||
|         <label for="menuToggler" class="toggler__label">
 | ||
|             <span></span>
 | ||
|         </label>
 | ||
|         <span class="nav-items-wrapper">
 | ||
|             <a href="https://www.python.org/" class="nav-logo">
 | ||
|                 <img src="../_static/py.svg" alt="Python logo"/>
 | ||
|             </a>
 | ||
|             <span class="version_switcher_placeholder"></span>
 | ||
|             <form role="search" class="search" action="../search.html" method="get">
 | ||
|                 <svg xmlns="http://www.w3.org/2000/svg" width="20" height="20" viewBox="0 0 24 24" class="search-icon">
 | ||
|                     <path fill-rule="nonzero" fill="currentColor" d="M15.5 14h-.79l-.28-.27a6.5 6.5 0 001.48-5.34c-.47-2.78-2.79-5-5.59-5.34a6.505 6.505 0 00-7.27 7.27c.34 2.8 2.56 5.12 5.34 5.59a6.5 6.5 0 005.34-1.48l.27.28v.79l4.25 4.25c.41.41 1.08.41 1.49 0 .41-.41.41-1.08 0-1.49L15.5 14zm-6 0C7.01 14 5 11.99 5 9.5S7.01 5 9.5 5 14 7.01 14 9.5 11.99 14 9.5 14z"></path>
 | ||
|                 </svg>
 | ||
|                 <input placeholder="Quick search" aria-label="Quick search" type="search" name="q" />
 | ||
|                 <input type="submit" value="Go"/>
 | ||
|             </form>
 | ||
|         </span>
 | ||
|     </nav>
 | ||
|     <div class="menu-wrapper">
 | ||
|         <nav class="menu" role="navigation" aria-label="main navigation">
 | ||
|             <div class="language_switcher_placeholder"></div>
 | ||
|             
 | ||
| <label class="theme-selector-label">
 | ||
|     Theme
 | ||
|     <select class="theme-selector" oninput="activateTheme(this.value)">
 | ||
|         <option value="auto" selected>Auto</option>
 | ||
|         <option value="light">Light</option>
 | ||
|         <option value="dark">Dark</option>
 | ||
|     </select>
 | ||
| </label>
 | ||
|   <div>
 | ||
|     <h3><a href="../contents.html">Table of Contents</a></h3>
 | ||
|     <ul>
 | ||
| <li><a class="reference internal" href="#">What’s New in Python 2.1</a><ul>
 | ||
| <li><a class="reference internal" href="#introduction">Introduction</a></li>
 | ||
| <li><a class="reference internal" href="#pep-227-nested-scopes">PEP 227: Nested Scopes</a></li>
 | ||
| <li><a class="reference internal" href="#pep-236-future-directives">PEP 236: __future__ Directives</a></li>
 | ||
| <li><a class="reference internal" href="#pep-207-rich-comparisons">PEP 207: Rich Comparisons</a></li>
 | ||
| <li><a class="reference internal" href="#pep-230-warning-framework">PEP 230: Warning Framework</a></li>
 | ||
| <li><a class="reference internal" href="#pep-229-new-build-system">PEP 229: New Build System</a></li>
 | ||
| <li><a class="reference internal" href="#pep-205-weak-references">PEP 205: Weak References</a></li>
 | ||
| <li><a class="reference internal" href="#pep-232-function-attributes">PEP 232: Function Attributes</a></li>
 | ||
| <li><a class="reference internal" href="#pep-235-importing-modules-on-case-insensitive-platforms">PEP 235: Importing Modules on Case-Insensitive Platforms</a></li>
 | ||
| <li><a class="reference internal" href="#pep-217-interactive-display-hook">PEP 217: Interactive Display Hook</a></li>
 | ||
| <li><a class="reference internal" href="#pep-208-new-coercion-model">PEP 208: New Coercion Model</a></li>
 | ||
| <li><a class="reference internal" href="#pep-241-metadata-in-python-packages">PEP 241: Metadata in Python Packages</a></li>
 | ||
| <li><a class="reference internal" href="#new-and-improved-modules">New and Improved Modules</a></li>
 | ||
| <li><a class="reference internal" href="#other-changes-and-fixes">Other Changes and Fixes</a></li>
 | ||
| <li><a class="reference internal" href="#acknowledgements">Acknowledgements</a></li>
 | ||
| </ul>
 | ||
| </li>
 | ||
| </ul>
 | ||
| 
 | ||
|   </div>
 | ||
|   <div>
 | ||
|     <h4>Previous topic</h4>
 | ||
|     <p class="topless"><a href="2.2.html"
 | ||
|                           title="previous chapter">What’s New in Python 2.2</a></p>
 | ||
|   </div>
 | ||
|   <div>
 | ||
|     <h4>Next topic</h4>
 | ||
|     <p class="topless"><a href="2.0.html"
 | ||
|                           title="next chapter">What’s New in Python 2.0</a></p>
 | ||
|   </div>
 | ||
|   <div role="note" aria-label="source link">
 | ||
|     <h3>This Page</h3>
 | ||
|     <ul class="this-page-menu">
 | ||
|       <li><a href="../bugs.html">Report a Bug</a></li>
 | ||
|       <li>
 | ||
|         <a href="https://github.com/python/cpython/blob/main/Doc/whatsnew/2.1.rst"
 | ||
|             rel="nofollow">Show Source
 | ||
|         </a>
 | ||
|       </li>
 | ||
|     </ul>
 | ||
|   </div>
 | ||
|         </nav>
 | ||
|     </div>
 | ||
| </div>
 | ||
| 
 | ||
|   
 | ||
|     <div class="related" role="navigation" aria-label="Related">
 | ||
|       <h3>Navigation</h3>
 | ||
|       <ul>
 | ||
|         <li class="right" style="margin-right: 10px">
 | ||
|           <a href="../genindex.html" title="General Index"
 | ||
|              accesskey="I">index</a></li>
 | ||
|         <li class="right" >
 | ||
|           <a href="../py-modindex.html" title="Python Module Index"
 | ||
|              >modules</a> |</li>
 | ||
|         <li class="right" >
 | ||
|           <a href="2.0.html" title="What’s New in Python 2.0"
 | ||
|              accesskey="N">next</a> |</li>
 | ||
|         <li class="right" >
 | ||
|           <a href="2.2.html" title="What’s New in Python 2.2"
 | ||
|              accesskey="P">previous</a> |</li>
 | ||
| 
 | ||
|           <li><img src="../_static/py.svg" alt="Python logo" style="vertical-align: middle; margin-top: -1px"/></li>
 | ||
|           <li><a href="https://www.python.org/">Python</a> »</li>
 | ||
|           <li class="switchers">
 | ||
|             <div class="language_switcher_placeholder"></div>
 | ||
|             <div class="version_switcher_placeholder"></div>
 | ||
|           </li>
 | ||
|           <li>
 | ||
|               
 | ||
|           </li>
 | ||
|     <li id="cpython-language-and-version">
 | ||
|       <a href="../index.html">3.13.3 Documentation</a> »
 | ||
|     </li>
 | ||
| 
 | ||
|           <li class="nav-item nav-item-1"><a href="index.html" accesskey="U">What’s New in Python</a> »</li>
 | ||
|         <li class="nav-item nav-item-this"><a href="">What’s New in Python 2.1</a></li>
 | ||
|                 <li class="right">
 | ||
|                     
 | ||
| 
 | ||
|     <div class="inline-search" role="search">
 | ||
|         <form class="inline-search" action="../search.html" method="get">
 | ||
|           <input placeholder="Quick search" aria-label="Quick search" type="search" name="q" id="search-box" />
 | ||
|           <input type="submit" value="Go" />
 | ||
|         </form>
 | ||
|     </div>
 | ||
|                      |
 | ||
|                 </li>
 | ||
|             <li class="right">
 | ||
| <label class="theme-selector-label">
 | ||
|     Theme
 | ||
|     <select class="theme-selector" oninput="activateTheme(this.value)">
 | ||
|         <option value="auto" selected>Auto</option>
 | ||
|         <option value="light">Light</option>
 | ||
|         <option value="dark">Dark</option>
 | ||
|     </select>
 | ||
| </label> |</li>
 | ||
|             
 | ||
|       </ul>
 | ||
|     </div>    
 | ||
| 
 | ||
|     <div class="document">
 | ||
|       <div class="documentwrapper">
 | ||
|         <div class="bodywrapper">
 | ||
|           <div class="body" role="main">
 | ||
|             
 | ||
|   <section id="what-s-new-in-python-2-1">
 | ||
| <h1>What’s New in Python 2.1<a class="headerlink" href="#what-s-new-in-python-2-1" title="Link to this heading">¶</a></h1>
 | ||
| <dl class="field-list simple">
 | ||
| <dt class="field-odd">Author<span class="colon">:</span></dt>
 | ||
| <dd class="field-odd"><p>A.M. Kuchling</p>
 | ||
| </dd>
 | ||
| </dl>
 | ||
| <section id="introduction">
 | ||
| <h2>Introduction<a class="headerlink" href="#introduction" title="Link to this heading">¶</a></h2>
 | ||
| <p>This article explains the new features in Python 2.1.  While there aren’t as
 | ||
| many changes in 2.1 as there were in Python 2.0, there are still some pleasant
 | ||
| surprises in store.  2.1 is the first release to be steered through the use of
 | ||
| Python Enhancement Proposals, or PEPs, so most of the sizable changes have
 | ||
| accompanying PEPs that provide more complete documentation and a design
 | ||
| rationale for the change.  This article doesn’t attempt to document the new
 | ||
| features completely, but simply provides an overview of the new features for
 | ||
| Python programmers. Refer to the Python 2.1 documentation, or to the specific
 | ||
| PEP, for more details about any new feature that particularly interests you.</p>
 | ||
| <p>One recent goal of the Python development team has been to accelerate the pace
 | ||
| of new releases, with a new release coming every 6 to 9 months. 2.1 is the first
 | ||
| release to come out at this faster pace, with the first alpha appearing in
 | ||
| January, 3 months after the final version of 2.0 was released.</p>
 | ||
| <p>The final release of Python 2.1 was made on April 17, 2001.</p>
 | ||
| </section>
 | ||
| <section id="pep-227-nested-scopes">
 | ||
| <h2>PEP 227: Nested Scopes<a class="headerlink" href="#pep-227-nested-scopes" title="Link to this heading">¶</a></h2>
 | ||
| <p>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 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:</p>
 | ||
| <div class="highlight-python3 notranslate"><div class="highlight"><pre><span></span><span class="k">def</span><span class="w"> </span><span class="nf">f</span><span class="p">():</span>
 | ||
|     <span class="o">...</span>
 | ||
|     <span class="k">def</span><span class="w"> </span><span class="nf">g</span><span class="p">(</span><span class="n">value</span><span class="p">):</span>
 | ||
|         <span class="o">...</span>
 | ||
|         <span class="k">return</span> <span class="n">g</span><span class="p">(</span><span class="n">value</span><span class="o">-</span><span class="mi">1</span><span class="p">)</span> <span class="o">+</span> <span class="mi">1</span>
 | ||
|     <span class="o">...</span>
 | ||
| </pre></div>
 | ||
| </div>
 | ||
| <p>The function <code class="xref py py-func docutils literal notranslate"><span class="pre">g()</span></code> will always raise a <a class="reference internal" href="../library/exceptions.html#NameError" title="NameError"><code class="xref py py-exc docutils literal notranslate"><span class="pre">NameError</span></code></a> exception, because
 | ||
| the binding of the name <code class="docutils literal notranslate"><span class="pre">g</span></code> 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 <a class="reference internal" href="../reference/expressions.html#lambda"><code class="xref std std-keyword docutils literal notranslate"><span class="pre">lambda</span></code></a> expression clumsier, and this was a problem in practice.
 | ||
| In code which uses <a class="reference internal" href="../reference/expressions.html#lambda"><code class="xref std std-keyword docutils literal notranslate"><span class="pre">lambda</span></code></a> you can often find local variables being
 | ||
| copied by passing them as the default values of arguments.</p>
 | ||
| <div class="highlight-python3 notranslate"><div class="highlight"><pre><span></span><span class="k">def</span><span class="w"> </span><span class="nf">find</span><span class="p">(</span><span class="bp">self</span><span class="p">,</span> <span class="n">name</span><span class="p">):</span>
 | ||
|     <span class="s2">"Return list of any entries equal to 'name'"</span>
 | ||
|     <span class="n">L</span> <span class="o">=</span> <span class="nb">filter</span><span class="p">(</span><span class="k">lambda</span> <span class="n">x</span><span class="p">,</span> <span class="n">name</span><span class="o">=</span><span class="n">name</span><span class="p">:</span> <span class="n">x</span> <span class="o">==</span> <span class="n">name</span><span class="p">,</span>
 | ||
|                <span class="bp">self</span><span class="o">.</span><span class="n">list_attribute</span><span class="p">)</span>
 | ||
|     <span class="k">return</span> <span class="n">L</span>
 | ||
| </pre></div>
 | ||
| </div>
 | ||
| <p>The readability of Python code written in a strongly functional style suffers
 | ||
| greatly as a result.</p>
 | ||
| <p>The most significant change to Python 2.1 is that static scoping has been added
 | ||
| to the language to fix this problem.  As a first effect, the <code class="docutils literal notranslate"><span class="pre">name=name</span></code>
 | ||
| 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 <a class="reference internal" href="../reference/compound_stmts.html#def"><code class="xref std std-keyword docutils literal notranslate"><span class="pre">def</span></code></a>, <a class="reference internal" href="../reference/compound_stmts.html#class"><code class="xref std std-keyword docutils literal notranslate"><span class="pre">class</span></code></a>, or <a class="reference internal" href="../reference/simple_stmts.html#import"><code class="xref std std-keyword docutils literal notranslate"><span class="pre">import</span></code></a> 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.</p>
 | ||
| <p>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.</p>
 | ||
| <p>One side effect of the change is that the <code class="docutils literal notranslate"><span class="pre">from</span> <span class="pre">module</span> <span class="pre">import</span> <span class="pre">*</span></code> and
 | ||
| <code class="docutils literal notranslate"><span class="pre">exec</span></code> statements have been made illegal inside a function scope under
 | ||
| certain conditions.  The Python reference manual has said all along that <code class="docutils literal notranslate"><span class="pre">from</span>
 | ||
| <span class="pre">module</span> <span class="pre">import</span> <span class="pre">*</span></code> 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 class="docutils literal notranslate"><span class="pre">from</span>
 | ||
| <span class="pre">module</span> <span class="pre">import</span> <span class="pre">*</span></code> and <code class="docutils literal notranslate"><span class="pre">exec</span></code> 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 <a class="reference internal" href="../reference/expressions.html#lambda"><code class="xref std std-keyword docutils literal notranslate"><span class="pre">lambda</span></code></a> expressions with free variables, the compiler
 | ||
| will flag this by raising a <a class="reference internal" href="../library/exceptions.html#SyntaxError" title="SyntaxError"><code class="xref py py-exc docutils literal notranslate"><span class="pre">SyntaxError</span></code></a> exception.</p>
 | ||
| <p>To make the preceding explanation a bit clearer, here’s an example:</p>
 | ||
| <div class="highlight-python3 notranslate"><div class="highlight"><pre><span></span><span class="n">x</span> <span class="o">=</span> <span class="mi">1</span>
 | ||
| <span class="k">def</span><span class="w"> </span><span class="nf">f</span><span class="p">():</span>
 | ||
|     <span class="c1"># The next line is a syntax error</span>
 | ||
|     <span class="n">exec</span> <span class="s1">'x=2'</span>
 | ||
|     <span class="k">def</span><span class="w"> </span><span class="nf">g</span><span class="p">():</span>
 | ||
|         <span class="k">return</span> <span class="n">x</span>
 | ||
| </pre></div>
 | ||
| </div>
 | ||
| <p>Line 4 containing the <code class="docutils literal notranslate"><span class="pre">exec</span></code> statement is a syntax error, since
 | ||
| <code class="docutils literal notranslate"><span class="pre">exec</span></code> would define a new local variable named <code class="docutils literal notranslate"><span class="pre">x</span></code> whose value should
 | ||
| be accessed by <code class="xref py py-func docutils literal notranslate"><span class="pre">g()</span></code>.</p>
 | ||
| <p>This shouldn’t be much of a limitation, since <code class="docutils literal notranslate"><span class="pre">exec</span></code> is rarely used in
 | ||
| most Python code (and when it is used, it’s often a sign of a poor design
 | ||
| anyway).</p>
 | ||
| <p>Compatibility concerns have led to nested scopes being introduced gradually; in
 | ||
| Python 2.1, they aren’t enabled by default, but can be turned on within a module
 | ||
| by using a future statement as described in <span class="target" id="index-0"></span><a class="pep reference external" href="https://peps.python.org/pep-0236/"><strong>PEP 236</strong></a>.  (See the following section
 | ||
| for further discussion of <span class="target" id="index-1"></span><a class="pep reference external" href="https://peps.python.org/pep-0236/"><strong>PEP 236</strong></a>.)  In Python 2.2, nested scopes will become
 | ||
| the default and there will be no way to turn them off, but users will have had
 | ||
| all of 2.1’s lifetime to fix any breakage resulting from their introduction.</p>
 | ||
| <div class="admonition seealso">
 | ||
| <p class="admonition-title">See also</p>
 | ||
| <dl class="simple">
 | ||
| <dt><span class="target" id="index-2"></span><a class="pep reference external" href="https://peps.python.org/pep-0227/"><strong>PEP 227</strong></a> - Statically Nested Scopes</dt><dd><p>Written and implemented by Jeremy Hylton.</p>
 | ||
| </dd>
 | ||
| </dl>
 | ||
| </div>
 | ||
| </section>
 | ||
| <section id="pep-236-future-directives">
 | ||
| <h2>PEP 236: __future__ Directives<a class="headerlink" href="#pep-236-future-directives" title="Link to this heading">¶</a></h2>
 | ||
| <p>The reaction to nested scopes was widespread concern about the dangers of
 | ||
| breaking code with the 2.1 release, and it was strong enough to make the
 | ||
| Pythoneers take a more conservative approach.  This approach consists of
 | ||
| introducing a convention for enabling optional functionality in release N that
 | ||
| will become compulsory in release N+1.</p>
 | ||
| <p>The syntax uses a <code class="docutils literal notranslate"><span class="pre">from...import</span></code> statement using the reserved module name
 | ||
| <a class="reference internal" href="../library/__future__.html#module-__future__" title="__future__: Future statement definitions"><code class="xref py py-mod docutils literal notranslate"><span class="pre">__future__</span></code></a>.  Nested scopes can be enabled by the following statement:</p>
 | ||
| <div class="highlight-python3 notranslate"><div class="highlight"><pre><span></span><span class="kn">from</span><span class="w"> </span><span class="nn">__future__</span><span class="w"> </span><span class="kn">import</span> <span class="n">nested_scopes</span>
 | ||
| </pre></div>
 | ||
| </div>
 | ||
| <p>While it looks like a normal <a class="reference internal" href="../reference/simple_stmts.html#import"><code class="xref std std-keyword docutils literal notranslate"><span class="pre">import</span></code></a> statement, it’s not; there are
 | ||
| strict rules on where such a future statement can be put. They can only be at
 | ||
| the top of a module, and must precede any Python code or regular
 | ||
| <code class="xref std std-keyword docutils literal notranslate"><span class="pre">import</span></code> statements.  This is because such statements can affect how
 | ||
| the Python bytecode compiler parses code and generates bytecode, so they must
 | ||
| precede any statement that will result in bytecodes being produced.</p>
 | ||
| <div class="admonition seealso">
 | ||
| <p class="admonition-title">See also</p>
 | ||
| <dl class="simple">
 | ||
| <dt><span class="target" id="index-3"></span><a class="pep reference external" href="https://peps.python.org/pep-0236/"><strong>PEP 236</strong></a> - Back to the <a class="reference internal" href="../library/__future__.html#module-__future__" title="__future__: Future statement definitions"><code class="xref py py-mod docutils literal notranslate"><span class="pre">__future__</span></code></a></dt><dd><p>Written by Tim Peters, and primarily implemented by Jeremy Hylton.</p>
 | ||
| </dd>
 | ||
| </dl>
 | ||
| </div>
 | ||
| </section>
 | ||
| <section id="pep-207-rich-comparisons">
 | ||
| <h2>PEP 207: Rich Comparisons<a class="headerlink" href="#pep-207-rich-comparisons" title="Link to this heading">¶</a></h2>
 | ||
| <p>In earlier versions, Python’s support for implementing comparisons on user-defined
 | ||
| classes and extension types was quite simple. Classes could implement a
 | ||
| <code class="xref py py-meth docutils literal notranslate"><span class="pre">__cmp__()</span></code> method that was given two instances of a class, and could only
 | ||
| return 0 if they were equal or +1 or -1 if they weren’t; the method couldn’t
 | ||
| raise an exception or return anything other than a Boolean value.  Users of
 | ||
| Numeric Python often found this model too weak and restrictive, because in the
 | ||
| number-crunching programs that numeric Python is used for, it would be more
 | ||
| useful to be able to perform elementwise comparisons of two matrices, returning
 | ||
| a matrix containing the results of a given comparison for each element.  If the
 | ||
| two matrices are of different sizes, then the compare has to be able to raise an
 | ||
| exception to signal the error.</p>
 | ||
| <p>In Python 2.1, rich comparisons were added in order to support this need.
 | ||
| Python classes can now individually overload each of the <code class="docutils literal notranslate"><span class="pre"><</span></code>, <code class="docutils literal notranslate"><span class="pre"><=</span></code>, <code class="docutils literal notranslate"><span class="pre">></span></code>,
 | ||
| <code class="docutils literal notranslate"><span class="pre">>=</span></code>, <code class="docutils literal notranslate"><span class="pre">==</span></code>, and <code class="docutils literal notranslate"><span class="pre">!=</span></code> operations.  The new magic method names are:</p>
 | ||
| <table class="docutils align-default">
 | ||
| <thead>
 | ||
| <tr class="row-odd"><th class="head"><p>Operation</p></th>
 | ||
| <th class="head"><p>Method name</p></th>
 | ||
| </tr>
 | ||
| </thead>
 | ||
| <tbody>
 | ||
| <tr class="row-even"><td><p><code class="docutils literal notranslate"><span class="pre"><</span></code></p></td>
 | ||
| <td><p><a class="reference internal" href="../reference/datamodel.html#object.__lt__" title="object.__lt__"><code class="xref py py-meth docutils literal notranslate"><span class="pre">__lt__()</span></code></a></p></td>
 | ||
| </tr>
 | ||
| <tr class="row-odd"><td><p><code class="docutils literal notranslate"><span class="pre"><=</span></code></p></td>
 | ||
| <td><p><a class="reference internal" href="../reference/datamodel.html#object.__le__" title="object.__le__"><code class="xref py py-meth docutils literal notranslate"><span class="pre">__le__()</span></code></a></p></td>
 | ||
| </tr>
 | ||
| <tr class="row-even"><td><p><code class="docutils literal notranslate"><span class="pre">></span></code></p></td>
 | ||
| <td><p><a class="reference internal" href="../reference/datamodel.html#object.__gt__" title="object.__gt__"><code class="xref py py-meth docutils literal notranslate"><span class="pre">__gt__()</span></code></a></p></td>
 | ||
| </tr>
 | ||
| <tr class="row-odd"><td><p><code class="docutils literal notranslate"><span class="pre">>=</span></code></p></td>
 | ||
| <td><p><a class="reference internal" href="../reference/datamodel.html#object.__ge__" title="object.__ge__"><code class="xref py py-meth docutils literal notranslate"><span class="pre">__ge__()</span></code></a></p></td>
 | ||
| </tr>
 | ||
| <tr class="row-even"><td><p><code class="docutils literal notranslate"><span class="pre">==</span></code></p></td>
 | ||
| <td><p><a class="reference internal" href="../reference/datamodel.html#object.__eq__" title="object.__eq__"><code class="xref py py-meth docutils literal notranslate"><span class="pre">__eq__()</span></code></a></p></td>
 | ||
| </tr>
 | ||
| <tr class="row-odd"><td><p><code class="docutils literal notranslate"><span class="pre">!=</span></code></p></td>
 | ||
| <td><p><a class="reference internal" href="../reference/datamodel.html#object.__ne__" title="object.__ne__"><code class="xref py py-meth docutils literal notranslate"><span class="pre">__ne__()</span></code></a></p></td>
 | ||
| </tr>
 | ||
| </tbody>
 | ||
| </table>
 | ||
| <p>(The magic methods are named after the corresponding Fortran operators <code class="docutils literal notranslate"><span class="pre">.LT.</span></code>.
 | ||
| <code class="docutils literal notranslate"><span class="pre">.LE.</span></code>, &c.  Numeric programmers are almost certainly quite familiar with
 | ||
| these names and will find them easy to remember.)</p>
 | ||
| <p>Each of these magic methods is of the form <code class="docutils literal notranslate"><span class="pre">method(self,</span> <span class="pre">other)</span></code>, where
 | ||
| <code class="docutils literal notranslate"><span class="pre">self</span></code> will be the object on the left-hand side of the operator, while
 | ||
| <code class="docutils literal notranslate"><span class="pre">other</span></code> will be the object on the right-hand side.  For example, the
 | ||
| expression <code class="docutils literal notranslate"><span class="pre">A</span> <span class="pre"><</span> <span class="pre">B</span></code> will cause <code class="docutils literal notranslate"><span class="pre">A.__lt__(B)</span></code> to be called.</p>
 | ||
| <p>Each of these magic methods can return anything at all: a Boolean, a matrix, a
 | ||
| list, or any other Python object.  Alternatively they can raise an exception if
 | ||
| the comparison is impossible, inconsistent, or otherwise meaningless.</p>
 | ||
| <p>The built-in <code class="docutils literal notranslate"><span class="pre">cmp(A,B)</span></code> function can use the rich comparison machinery,
 | ||
| and now accepts an optional argument specifying which comparison operation to
 | ||
| use; this is given as one of the strings <code class="docutils literal notranslate"><span class="pre">"<"</span></code>, <code class="docutils literal notranslate"><span class="pre">"<="</span></code>, <code class="docutils literal notranslate"><span class="pre">">"</span></code>, <code class="docutils literal notranslate"><span class="pre">">="</span></code>,
 | ||
| <code class="docutils literal notranslate"><span class="pre">"=="</span></code>, or <code class="docutils literal notranslate"><span class="pre">"!="</span></code>.  If called without the optional third argument,
 | ||
| <code class="xref py py-func docutils literal notranslate"><span class="pre">cmp()</span></code> 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.</p>
 | ||
| <p>There are also corresponding changes of interest to C programmers; there’s a new
 | ||
| slot <code class="docutils literal notranslate"><span class="pre">tp_richcmp</span></code> in type objects and an API for performing a given rich
 | ||
| comparison.  I won’t cover the C API here, but will refer you to <span class="target" id="index-4"></span><a class="pep reference external" href="https://peps.python.org/pep-0207/"><strong>PEP 207</strong></a>, or to
 | ||
| 2.1’s C API documentation, for the full list of related functions.</p>
 | ||
| <div class="admonition seealso">
 | ||
| <p class="admonition-title">See also</p>
 | ||
| <dl class="simple">
 | ||
| <dt><span class="target" id="index-5"></span><a class="pep reference external" href="https://peps.python.org/pep-0207/"><strong>PEP 207</strong></a> - Rich Comparisons</dt><dd><p>Written by Guido van Rossum, heavily based on earlier work by David Ascher, and
 | ||
| implemented by Guido van Rossum.</p>
 | ||
| </dd>
 | ||
| </dl>
 | ||
| </div>
 | ||
| </section>
 | ||
| <section id="pep-230-warning-framework">
 | ||
| <h2>PEP 230: Warning Framework<a class="headerlink" href="#pep-230-warning-framework" title="Link to this heading">¶</a></h2>
 | ||
| <p>Over its 10 years of existence, Python has accumulated a certain number of
 | ||
| obsolete modules and features along the way.  It’s difficult to know when a
 | ||
| feature 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 enable
 | ||
| removing 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 a
 | ||
| warning in the next version of Python.  The following Python version can then
 | ||
| drop the feature, and users will have had a full release cycle to remove uses of
 | ||
| the old feature.</p>
 | ||
| <p>Python 2.1 adds the warning framework to be used in this scheme.  It adds a
 | ||
| <a class="reference internal" href="../library/warnings.html#module-warnings" title="warnings: Issue warning messages and control their disposition."><code class="xref py py-mod docutils literal notranslate"><span class="pre">warnings</span></code></a> module that provide functions to issue warnings, and to filter
 | ||
| out warnings that you don’t want to be displayed. Third-party modules can also
 | ||
| use this framework to deprecate old features that they no longer wish to
 | ||
| support.</p>
 | ||
| <p>For example, in Python 2.1 the <code class="xref py py-mod docutils literal notranslate"><span class="pre">regex</span></code> module is deprecated, so importing
 | ||
| it causes a warning to be printed:</p>
 | ||
| <div class="highlight-python3 notranslate"><div class="highlight"><pre><span></span><span class="gp">>>> </span><span class="kn">import</span><span class="w"> </span><span class="nn">regex</span>
 | ||
| <span class="go">__main__:1: DeprecationWarning: the regex module</span>
 | ||
| <span class="go">         is deprecated; please use the re module</span>
 | ||
| <span class="gp">>>></span>
 | ||
| </pre></div>
 | ||
| </div>
 | ||
| <p>Warnings can be issued by calling the <a class="reference internal" href="../library/warnings.html#warnings.warn" title="warnings.warn"><code class="xref py py-func docutils literal notranslate"><span class="pre">warnings.warn()</span></code></a> function:</p>
 | ||
| <div class="highlight-python3 notranslate"><div class="highlight"><pre><span></span><span class="n">warnings</span><span class="o">.</span><span class="n">warn</span><span class="p">(</span><span class="s2">"feature X no longer supported"</span><span class="p">)</span>
 | ||
| </pre></div>
 | ||
| </div>
 | ||
| <p>The first parameter is the warning message; an additional optional parameters
 | ||
| can be used to specify a particular warning category.</p>
 | ||
| <p>Filters can be added to disable certain warnings; a regular expression pattern
 | ||
| can be applied to the message or to the module name in order to suppress a
 | ||
| warning.  For example, you may have a program that uses the <code class="xref py py-mod docutils literal notranslate"><span class="pre">regex</span></code> module
 | ||
| and not want to spare the time to convert it to use the <a class="reference internal" href="../library/re.html#module-re" title="re: Regular expression operations."><code class="xref py py-mod docutils literal notranslate"><span class="pre">re</span></code></a> module right
 | ||
| now.  The warning can be suppressed by calling</p>
 | ||
| <div class="highlight-python3 notranslate"><div class="highlight"><pre><span></span><span class="kn">import</span><span class="w"> </span><span class="nn">warnings</span>
 | ||
| <span class="n">warnings</span><span class="o">.</span><span class="n">filterwarnings</span><span class="p">(</span><span class="n">action</span> <span class="o">=</span> <span class="s1">'ignore'</span><span class="p">,</span>
 | ||
|                         <span class="n">message</span><span class="o">=</span><span class="s1">'.*regex module is deprecated'</span><span class="p">,</span>
 | ||
|                         <span class="n">category</span><span class="o">=</span><span class="ne">DeprecationWarning</span><span class="p">,</span>
 | ||
|                         <span class="n">module</span> <span class="o">=</span> <span class="s1">'__main__'</span><span class="p">)</span>
 | ||
| </pre></div>
 | ||
| </div>
 | ||
| <p>This adds a filter that will apply only to warnings of the class
 | ||
| <a class="reference internal" href="../library/exceptions.html#DeprecationWarning" title="DeprecationWarning"><code class="xref py py-class docutils literal notranslate"><span class="pre">DeprecationWarning</span></code></a> triggered in the <a class="reference internal" href="../library/__main__.html#module-__main__" title="__main__: The environment where top-level code is run. Covers command-line interfaces, import-time behavior, and ``__name__ == '__main__'``."><code class="xref py py-mod docutils literal notranslate"><span class="pre">__main__</span></code></a> module, and applies
 | ||
| a regular expression to only match the message about the <code class="xref py py-mod docutils literal notranslate"><span class="pre">regex</span></code> module
 | ||
| being deprecated, and will cause such warnings to be ignored.  Warnings can also
 | ||
| be printed only once, printed every time the offending code is executed, or
 | ||
| turned into exceptions that will cause the program to stop (unless the
 | ||
| exceptions are caught in the usual way, of course).</p>
 | ||
| <p>Functions were also added to Python’s C API for issuing warnings; refer to PEP
 | ||
| 230 or to Python’s API documentation for the details.</p>
 | ||
| <div class="admonition seealso">
 | ||
| <p class="admonition-title">See also</p>
 | ||
| <dl class="simple">
 | ||
| <dt><span class="target" id="index-6"></span><a class="pep reference external" href="https://peps.python.org/pep-0005/"><strong>PEP 5</strong></a> - Guidelines for Language Evolution</dt><dd><p>Written by Paul Prescod, to specify procedures to be followed when removing old
 | ||
| features from Python.  The policy described in this PEP hasn’t been officially
 | ||
| adopted, but the eventual policy probably won’t be too different from Prescod’s
 | ||
| proposal.</p>
 | ||
| </dd>
 | ||
| <dt><span class="target" id="index-7"></span><a class="pep reference external" href="https://peps.python.org/pep-0230/"><strong>PEP 230</strong></a> - Warning Framework</dt><dd><p>Written and implemented by Guido van Rossum.</p>
 | ||
| </dd>
 | ||
| </dl>
 | ||
| </div>
 | ||
| </section>
 | ||
| <section id="pep-229-new-build-system">
 | ||
| <h2>PEP 229: New Build System<a class="headerlink" href="#pep-229-new-build-system" title="Link to this heading">¶</a></h2>
 | ||
| <p>When compiling Python, the user had to go in and edit the <code class="file docutils literal notranslate"><span class="pre">Modules/Setup</span></code>
 | ||
| file in order to enable various additional modules; the default set is
 | ||
| relatively 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.</p>
 | ||
| <p>Python 2.0 added the Distutils, a set of modules for distributing and installing
 | ||
| extensions.  In Python 2.1, the Distutils are used to compile much of the
 | ||
| standard library of extension modules, autodetecting which ones are supported on
 | ||
| the current machine.  It’s hoped that this will make Python installations easier
 | ||
| and more featureful.</p>
 | ||
| <p>Instead of having to edit the <code class="file docutils literal notranslate"><span class="pre">Modules/Setup</span></code> file in order to enable
 | ||
| modules, a <code class="file docutils literal notranslate"><span class="pre">setup.py</span></code> script in the top directory of the Python source
 | ||
| distribution is run at build time, and attempts to discover which modules can be
 | ||
| enabled by examining the modules and header files on the system.  If a module is
 | ||
| configured in <code class="file docutils literal notranslate"><span class="pre">Modules/Setup</span></code>, the <code class="file docutils literal notranslate"><span class="pre">setup.py</span></code> script won’t attempt
 | ||
| to compile that module and will defer to the <code class="file docutils literal notranslate"><span class="pre">Modules/Setup</span></code> file’s
 | ||
| contents.  This provides a way to specific any strange command-line flags or
 | ||
| libraries that are required for a specific platform.</p>
 | ||
| <p>In another far-reaching change to the build mechanism, Neil Schemenauer
 | ||
| restructured things so Python now uses a single makefile that isn’t recursive,
 | ||
| instead of makefiles in the top directory and in each of the <code class="file docutils literal notranslate"><span class="pre">Python/</span></code>,
 | ||
| <code class="file docutils literal notranslate"><span class="pre">Parser/</span></code>, <code class="file docutils literal notranslate"><span class="pre">Objects/</span></code>, and <code class="file docutils literal notranslate"><span class="pre">Modules/</span></code> subdirectories.  This
 | ||
| makes building Python faster and also makes hacking the Makefiles clearer and
 | ||
| simpler.</p>
 | ||
| <div class="admonition seealso">
 | ||
| <p class="admonition-title">See also</p>
 | ||
| <dl class="simple">
 | ||
| <dt><span class="target" id="index-8"></span><a class="pep reference external" href="https://peps.python.org/pep-0229/"><strong>PEP 229</strong></a> - Using Distutils to Build Python</dt><dd><p>Written and implemented by A.M. Kuchling.</p>
 | ||
| </dd>
 | ||
| </dl>
 | ||
| </div>
 | ||
| </section>
 | ||
| <section id="pep-205-weak-references">
 | ||
| <h2>PEP 205: Weak References<a class="headerlink" href="#pep-205-weak-references" title="Link to this heading">¶</a></h2>
 | ||
| <p>Weak references, available through the <a class="reference internal" href="../library/weakref.html#module-weakref" title="weakref: Support for weak references and weak dictionaries."><code class="xref py py-mod docutils literal notranslate"><span class="pre">weakref</span></code></a> module, are a minor but
 | ||
| useful new data type in the Python programmer’s toolbox.</p>
 | ||
| <p>Storing a reference to an object (say, in a dictionary or a list) has the side
 | ||
| effect of keeping that object alive forever.  There are a few specific cases
 | ||
| where this behaviour is undesirable, object caches being the most common one,
 | ||
| and another being circular references in data structures such as trees.</p>
 | ||
| <p>For example, consider a memoizing function that caches the results of another
 | ||
| function <code class="docutils literal notranslate"><span class="pre">f(x)</span></code> by storing the function’s argument and its result in a
 | ||
| dictionary:</p>
 | ||
| <div class="highlight-python3 notranslate"><div class="highlight"><pre><span></span><span class="n">_cache</span> <span class="o">=</span> <span class="p">{}</span>
 | ||
| <span class="k">def</span><span class="w"> </span><span class="nf">memoize</span><span class="p">(</span><span class="n">x</span><span class="p">):</span>
 | ||
|     <span class="k">if</span> <span class="n">_cache</span><span class="o">.</span><span class="n">has_key</span><span class="p">(</span><span class="n">x</span><span class="p">):</span>
 | ||
|         <span class="k">return</span> <span class="n">_cache</span><span class="p">[</span><span class="n">x</span><span class="p">]</span>
 | ||
| 
 | ||
|     <span class="n">retval</span> <span class="o">=</span> <span class="n">f</span><span class="p">(</span><span class="n">x</span><span class="p">)</span>
 | ||
| 
 | ||
|     <span class="c1"># Cache the returned object</span>
 | ||
|     <span class="n">_cache</span><span class="p">[</span><span class="n">x</span><span class="p">]</span> <span class="o">=</span> <span class="n">retval</span>
 | ||
| 
 | ||
|     <span class="k">return</span> <span class="n">retval</span>
 | ||
| </pre></div>
 | ||
| </div>
 | ||
| <p>This version works for simple things such as integers, but it has a side effect;
 | ||
| the <code class="docutils literal notranslate"><span class="pre">_cache</span></code> dictionary holds a reference to the return values, so they’ll
 | ||
| never be deallocated until the Python process exits and cleans up. This isn’t
 | ||
| very noticeable for integers, but if <code class="xref py py-func docutils literal notranslate"><span class="pre">f()</span></code> returns an object, or a data
 | ||
| structure that takes up a lot of memory, this can be a problem.</p>
 | ||
| <p>Weak references provide a way to implement a cache that won’t keep objects alive
 | ||
| beyond their time.  If an object is only accessible through weak references, the
 | ||
| object will be deallocated and the weak references will now indicate that the
 | ||
| object it referred to no longer exists.  A weak reference to an object <em>obj</em> is
 | ||
| created by calling <code class="docutils literal notranslate"><span class="pre">wr</span> <span class="pre">=</span> <span class="pre">weakref.ref(obj)</span></code>.  The object being referred to is
 | ||
| returned by calling the weak reference as if it were a function: <code class="docutils literal notranslate"><span class="pre">wr()</span></code>.  It
 | ||
| will return the referenced object, or <code class="docutils literal notranslate"><span class="pre">None</span></code> if the object no longer exists.</p>
 | ||
| <p>This makes it possible to write a <code class="xref py py-func docutils literal notranslate"><span class="pre">memoize()</span></code> function whose cache doesn’t
 | ||
| keep objects alive, by storing weak references in the cache.</p>
 | ||
| <div class="highlight-python3 notranslate"><div class="highlight"><pre><span></span><span class="n">_cache</span> <span class="o">=</span> <span class="p">{}</span>
 | ||
| <span class="k">def</span><span class="w"> </span><span class="nf">memoize</span><span class="p">(</span><span class="n">x</span><span class="p">):</span>
 | ||
|     <span class="k">if</span> <span class="n">_cache</span><span class="o">.</span><span class="n">has_key</span><span class="p">(</span><span class="n">x</span><span class="p">):</span>
 | ||
|         <span class="n">obj</span> <span class="o">=</span> <span class="n">_cache</span><span class="p">[</span><span class="n">x</span><span class="p">]()</span>
 | ||
|         <span class="c1"># If weak reference object still exists,</span>
 | ||
|         <span class="c1"># return it</span>
 | ||
|         <span class="k">if</span> <span class="n">obj</span> <span class="ow">is</span> <span class="ow">not</span> <span class="kc">None</span><span class="p">:</span> <span class="k">return</span> <span class="n">obj</span>
 | ||
| 
 | ||
|     <span class="n">retval</span> <span class="o">=</span> <span class="n">f</span><span class="p">(</span><span class="n">x</span><span class="p">)</span>
 | ||
| 
 | ||
|     <span class="c1"># Cache a weak reference</span>
 | ||
|     <span class="n">_cache</span><span class="p">[</span><span class="n">x</span><span class="p">]</span> <span class="o">=</span> <span class="n">weakref</span><span class="o">.</span><span class="n">ref</span><span class="p">(</span><span class="n">retval</span><span class="p">)</span>
 | ||
| 
 | ||
|     <span class="k">return</span> <span class="n">retval</span>
 | ||
| </pre></div>
 | ||
| </div>
 | ||
| <p>The <a class="reference internal" href="../library/weakref.html#module-weakref" title="weakref: Support for weak references and weak dictionaries."><code class="xref py py-mod docutils literal notranslate"><span class="pre">weakref</span></code></a> module also allows creating proxy objects which behave like
 | ||
| weak references — an object referenced only by proxy objects is deallocated –
 | ||
| but instead of requiring an explicit call to retrieve the object, the proxy
 | ||
| transparently forwards all operations to the object as long as the object still
 | ||
| exists.  If the object is deallocated, attempting to use a proxy will cause a
 | ||
| <code class="xref py py-exc docutils literal notranslate"><span class="pre">weakref.ReferenceError</span></code> exception to be raised.</p>
 | ||
| <div class="highlight-python3 notranslate"><div class="highlight"><pre><span></span><span class="n">proxy</span> <span class="o">=</span> <span class="n">weakref</span><span class="o">.</span><span class="n">proxy</span><span class="p">(</span><span class="n">obj</span><span class="p">)</span>
 | ||
| <span class="n">proxy</span><span class="o">.</span><span class="n">attr</span>   <span class="c1"># Equivalent to obj.attr</span>
 | ||
| <span class="n">proxy</span><span class="o">.</span><span class="n">meth</span><span class="p">()</span> <span class="c1"># Equivalent to obj.meth()</span>
 | ||
| <span class="k">del</span> <span class="n">obj</span>
 | ||
| <span class="n">proxy</span><span class="o">.</span><span class="n">attr</span>   <span class="c1"># raises weakref.ReferenceError</span>
 | ||
| </pre></div>
 | ||
| </div>
 | ||
| <div class="admonition seealso">
 | ||
| <p class="admonition-title">See also</p>
 | ||
| <dl class="simple">
 | ||
| <dt><span class="target" id="index-9"></span><a class="pep reference external" href="https://peps.python.org/pep-0205/"><strong>PEP 205</strong></a> - Weak References</dt><dd><p>Written and implemented by Fred L. Drake, Jr.</p>
 | ||
| </dd>
 | ||
| </dl>
 | ||
| </div>
 | ||
| </section>
 | ||
| <section id="pep-232-function-attributes">
 | ||
| <h2>PEP 232: Function Attributes<a class="headerlink" href="#pep-232-function-attributes" title="Link to this heading">¶</a></h2>
 | ||
| <p>In Python 2.1, functions can now have arbitrary information attached to them.
 | ||
| People were often using docstrings to hold information about functions and
 | ||
| methods, because the <a class="reference internal" href="../reference/datamodel.html#function.__doc__" title="function.__doc__"><code class="xref py py-attr docutils literal notranslate"><span class="pre">__doc__</span></code></a> attribute was the only way of
 | ||
| attaching any
 | ||
| information to a function.  For example, in the Zope web application server,
 | ||
| functions are marked as safe for public access by having a docstring, and in
 | ||
| John Aycock’s SPARK parsing framework, docstrings hold parts of the BNF grammar
 | ||
| to be parsed.  This overloading is unfortunate, since docstrings are really
 | ||
| intended to hold a function’s documentation; for example, it means you can’t
 | ||
| properly document functions intended for private use in Zope.</p>
 | ||
| <p>Arbitrary attributes can now be set and retrieved on functions using the regular
 | ||
| Python syntax:</p>
 | ||
| <div class="highlight-python3 notranslate"><div class="highlight"><pre><span></span><span class="k">def</span><span class="w"> </span><span class="nf">f</span><span class="p">():</span> <span class="k">pass</span>
 | ||
| 
 | ||
| <span class="n">f</span><span class="o">.</span><span class="n">publish</span> <span class="o">=</span> <span class="mi">1</span>
 | ||
| <span class="n">f</span><span class="o">.</span><span class="n">secure</span> <span class="o">=</span> <span class="mi">1</span>
 | ||
| <span class="n">f</span><span class="o">.</span><span class="n">grammar</span> <span class="o">=</span> <span class="s2">"A ::= B (C D)*"</span>
 | ||
| </pre></div>
 | ||
| </div>
 | ||
| <p>The dictionary containing attributes can be accessed as the function’s
 | ||
| <a class="reference internal" href="../reference/datamodel.html#function.__dict__" title="function.__dict__"><code class="xref py py-attr docutils literal notranslate"><span class="pre">__dict__</span></code></a>. Unlike the <a class="reference internal" href="../reference/datamodel.html#type.__dict__" title="type.__dict__"><code class="xref py py-attr docutils literal notranslate"><span class="pre">__dict__</span></code></a> attribute of class instances, in
 | ||
| functions you can actually assign a new dictionary to <a class="reference internal" href="../reference/datamodel.html#function.__dict__" title="function.__dict__"><code class="xref py py-attr docutils literal notranslate"><span class="pre">__dict__</span></code></a>, though
 | ||
| the new value is restricted to a regular Python dictionary; you <em>can’t</em> be
 | ||
| tricky and set it to a <code class="xref py py-class docutils literal notranslate"><span class="pre">UserDict</span></code> instance, or any other random object
 | ||
| that behaves like a mapping.</p>
 | ||
| <div class="admonition seealso">
 | ||
| <p class="admonition-title">See also</p>
 | ||
| <dl class="simple">
 | ||
| <dt><span class="target" id="index-10"></span><a class="pep reference external" href="https://peps.python.org/pep-0232/"><strong>PEP 232</strong></a> - Function Attributes</dt><dd><p>Written and implemented by Barry Warsaw.</p>
 | ||
| </dd>
 | ||
| </dl>
 | ||
| </div>
 | ||
| </section>
 | ||
| <section id="pep-235-importing-modules-on-case-insensitive-platforms">
 | ||
| <h2>PEP 235: Importing Modules on Case-Insensitive Platforms<a class="headerlink" href="#pep-235-importing-modules-on-case-insensitive-platforms" title="Link to this heading">¶</a></h2>
 | ||
| <p>Some operating systems have filesystems that are case-insensitive, MacOS and
 | ||
| Windows being the primary examples; on these systems, it’s impossible to
 | ||
| distinguish the filenames <code class="docutils literal notranslate"><span class="pre">FILE.PY</span></code> and <code class="docutils literal notranslate"><span class="pre">file.py</span></code>, even though they do store
 | ||
| the file’s name  in its original case (they’re case-preserving, too).</p>
 | ||
| <p>In Python 2.1, the <a class="reference internal" href="../reference/simple_stmts.html#import"><code class="xref std std-keyword docutils literal notranslate"><span class="pre">import</span></code></a> statement will work to simulate case-sensitivity
 | ||
| on case-insensitive platforms.  Python will now search for the first
 | ||
| case-sensitive match by default, raising an <a class="reference internal" href="../library/exceptions.html#ImportError" title="ImportError"><code class="xref py py-exc docutils literal notranslate"><span class="pre">ImportError</span></code></a> if no such file
 | ||
| is found, so <code class="docutils literal notranslate"><span class="pre">import</span> <span class="pre">file</span></code> will not import a module named <code class="docutils literal notranslate"><span class="pre">FILE.PY</span></code>.
 | ||
| Case-insensitive matching can be requested by setting the <span class="target" id="index-11"></span><a class="reference internal" href="../using/cmdline.html#envvar-PYTHONCASEOK"><code class="xref std std-envvar docutils literal notranslate"><span class="pre">PYTHONCASEOK</span></code></a>
 | ||
| environment variable before starting the Python interpreter.</p>
 | ||
| </section>
 | ||
| <section id="pep-217-interactive-display-hook">
 | ||
| <h2>PEP 217: Interactive Display Hook<a class="headerlink" href="#pep-217-interactive-display-hook" title="Link to this heading">¶</a></h2>
 | ||
| <p>When using the Python interpreter interactively, the output of commands is
 | ||
| displayed using the built-in <a class="reference internal" href="../library/functions.html#repr" title="repr"><code class="xref py py-func docutils literal notranslate"><span class="pre">repr()</span></code></a> function. In Python 2.1, the variable
 | ||
| <a class="reference internal" href="../library/sys.html#sys.displayhook" title="sys.displayhook"><code class="xref py py-func docutils literal notranslate"><span class="pre">sys.displayhook()</span></code></a> can be set to a callable object which will be called
 | ||
| instead of <a class="reference internal" href="../library/functions.html#repr" title="repr"><code class="xref py py-func docutils literal notranslate"><span class="pre">repr()</span></code></a>. For example, you can set it to a special
 | ||
| pretty-printing function:</p>
 | ||
| <div class="highlight-python3 notranslate"><div class="highlight"><pre><span></span><span class="gp">>>> </span><span class="c1"># Create a recursive data structure</span>
 | ||
| <span class="gp">... </span><span class="n">L</span> <span class="o">=</span> <span class="p">[</span><span class="mi">1</span><span class="p">,</span><span class="mi">2</span><span class="p">,</span><span class="mi">3</span><span class="p">]</span>
 | ||
| <span class="gp">>>> </span><span class="n">L</span><span class="o">.</span><span class="n">append</span><span class="p">(</span><span class="n">L</span><span class="p">)</span>
 | ||
| <span class="gp">>>> </span><span class="n">L</span> <span class="c1"># Show Python's default output</span>
 | ||
| <span class="go">[1, 2, 3, [...]]</span>
 | ||
| <span class="gp">>>> </span><span class="c1"># Use pprint.pprint() as the display function</span>
 | ||
| <span class="gp">... </span><span class="kn">import</span><span class="w"> </span><span class="nn">sys</span><span class="o">,</span><span class="w"> </span><span class="nn">pprint</span>
 | ||
| <span class="gp">>>> </span><span class="n">sys</span><span class="o">.</span><span class="n">displayhook</span> <span class="o">=</span> <span class="n">pprint</span><span class="o">.</span><span class="n">pprint</span>
 | ||
| <span class="gp">>>> </span><span class="n">L</span>
 | ||
| <span class="go">[1, 2, 3,  <Recursion on list with id=135143996>]</span>
 | ||
| <span class="gp">>>></span>
 | ||
| </pre></div>
 | ||
| </div>
 | ||
| <div class="admonition seealso">
 | ||
| <p class="admonition-title">See also</p>
 | ||
| <dl class="simple">
 | ||
| <dt><span class="target" id="index-12"></span><a class="pep reference external" href="https://peps.python.org/pep-0217/"><strong>PEP 217</strong></a> - Display Hook for Interactive Use</dt><dd><p>Written and implemented by Moshe Zadka.</p>
 | ||
| </dd>
 | ||
| </dl>
 | ||
| </div>
 | ||
| </section>
 | ||
| <section id="pep-208-new-coercion-model">
 | ||
| <h2>PEP 208: New Coercion Model<a class="headerlink" href="#pep-208-new-coercion-model" title="Link to this heading">¶</a></h2>
 | ||
| <p>How numeric coercion is done at the C level was significantly modified.  This
 | ||
| will only affect the authors of C extensions to Python, allowing them more
 | ||
| flexibility in writing extension types that support numeric operations.</p>
 | ||
| <p>Extension types can now set the type flag <code class="docutils literal notranslate"><span class="pre">Py_TPFLAGS_CHECKTYPES</span></code> in their
 | ||
| <code class="docutils literal notranslate"><span class="pre">PyTypeObject</span></code> structure to indicate that they support the new coercion model.
 | ||
| In such extension types, the numeric slot functions can no longer assume that
 | ||
| they’ll be passed two arguments of the same type; instead they may be passed two
 | ||
| arguments 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 the
 | ||
| failure by returning a reference to the <code class="docutils literal notranslate"><span class="pre">Py_NotImplemented</span></code> singleton value.
 | ||
| The numeric functions of the other type will then be tried, and perhaps they can
 | ||
| handle the operation; if the other type also returns <code class="docutils literal notranslate"><span class="pre">Py_NotImplemented</span></code>, then
 | ||
| a <a class="reference internal" href="../library/exceptions.html#TypeError" title="TypeError"><code class="xref py py-exc docutils literal notranslate"><span class="pre">TypeError</span></code></a> will be raised.  Numeric methods written in Python can also
 | ||
| return <code class="docutils literal notranslate"><span class="pre">Py_NotImplemented</span></code>, causing the interpreter to act as if the method
 | ||
| did not exist (perhaps raising a <a class="reference internal" href="../library/exceptions.html#TypeError" title="TypeError"><code class="xref py py-exc docutils literal notranslate"><span class="pre">TypeError</span></code></a>, perhaps trying another
 | ||
| object’s numeric methods).</p>
 | ||
| <div class="admonition seealso">
 | ||
| <p class="admonition-title">See also</p>
 | ||
| <dl class="simple">
 | ||
| <dt><span class="target" id="index-13"></span><a class="pep reference external" href="https://peps.python.org/pep-0208/"><strong>PEP 208</strong></a> - Reworking the Coercion Model</dt><dd><p>Written and implemented by Neil Schemenauer, heavily based upon earlier work by
 | ||
| Marc-André Lemburg.  Read this to understand the fine points of how numeric
 | ||
| operations will now be processed at the C level.</p>
 | ||
| </dd>
 | ||
| </dl>
 | ||
| </div>
 | ||
| </section>
 | ||
| <section id="pep-241-metadata-in-python-packages">
 | ||
| <h2>PEP 241: Metadata in Python Packages<a class="headerlink" href="#pep-241-metadata-in-python-packages" title="Link to this heading">¶</a></h2>
 | ||
| <p>A common complaint from Python users is that there’s no single catalog of all
 | ||
| the Python modules in existence.  T. Middleton’s Vaults of Parnassus at
 | ||
| <code class="docutils literal notranslate"><span class="pre">www.vex.net/parnassus/</span></code> (retired in February 2009, <a class="reference external" href="https://web.archive.org/web/20090130140102/http://www.vex.net/parnassus/">available in the
 | ||
| Internet Archive Wayback Machine</a>)
 | ||
| was the largest catalog of Python modules, but
 | ||
| registering software at the Vaults is optional, and many people did not bother.</p>
 | ||
| <p>As a first small step toward fixing the problem, Python software packaged using
 | ||
| the Distutils <strong class="command">sdist</strong> command will include a file named
 | ||
| <code class="file docutils literal notranslate"><span class="pre">PKG-INFO</span></code> containing information about the package such as its name,
 | ||
| version, and author (metadata, in cataloguing terminology).  <span class="target" id="index-14"></span><a class="pep reference external" href="https://peps.python.org/pep-0241/"><strong>PEP 241</strong></a> contains
 | ||
| the full list of fields that can be present in the <code class="file docutils literal notranslate"><span class="pre">PKG-INFO</span></code> file.  As
 | ||
| people began to package their software using Python 2.1, more and more packages
 | ||
| will include metadata, making it possible to build automated cataloguing systems
 | ||
| and experiment with them.  With the result experience, perhaps it’ll be possible
 | ||
| to design a really good catalog and then build support for it into Python 2.2.
 | ||
| For example, the Distutils <strong class="command">sdist</strong> and <strong class="command">bdist_*</strong> commands
 | ||
| could support an <code class="docutils literal notranslate"><span class="pre">upload</span></code> option that would automatically upload your
 | ||
| package to a catalog server.</p>
 | ||
| <p>You can start creating packages containing <code class="file docutils literal notranslate"><span class="pre">PKG-INFO</span></code> even if you’re not
 | ||
| using Python 2.1, since a new release of the Distutils will be made for users of
 | ||
| earlier Python versions.  Version 1.0.2 of the Distutils includes the changes
 | ||
| described in <span class="target" id="index-15"></span><a class="pep reference external" href="https://peps.python.org/pep-0241/"><strong>PEP 241</strong></a>, as well as various bugfixes and enhancements.  It will be
 | ||
| available from the Distutils SIG at <a class="reference external" href="https://www.python.org/community/sigs/current/distutils-sig/">https://www.python.org/community/sigs/current/distutils-sig/</a>.</p>
 | ||
| <div class="admonition seealso">
 | ||
| <p class="admonition-title">See also</p>
 | ||
| <dl class="simple">
 | ||
| <dt><span class="target" id="index-16"></span><a class="pep reference external" href="https://peps.python.org/pep-0241/"><strong>PEP 241</strong></a> - Metadata for Python Software Packages</dt><dd><p>Written and implemented by A.M. Kuchling.</p>
 | ||
| </dd>
 | ||
| <dt><span class="target" id="index-17"></span><a class="pep reference external" href="https://peps.python.org/pep-0243/"><strong>PEP 243</strong></a> - Module Repository Upload Mechanism</dt><dd><p>Written by Sean Reifschneider, this draft PEP describes a proposed mechanism for
 | ||
| uploading  Python packages to a central server.</p>
 | ||
| </dd>
 | ||
| </dl>
 | ||
| </div>
 | ||
| </section>
 | ||
| <section id="new-and-improved-modules">
 | ||
| <h2>New and Improved Modules<a class="headerlink" href="#new-and-improved-modules" title="Link to this heading">¶</a></h2>
 | ||
| <ul>
 | ||
| <li><p>Ka-Ping Yee contributed two new modules: <code class="xref py py-mod docutils literal notranslate"><span class="pre">inspect.py</span></code>, a module for
 | ||
| getting information about live Python code, and <code class="xref py py-mod docutils literal notranslate"><span class="pre">pydoc.py</span></code>, a module for
 | ||
| interactively converting docstrings to HTML or text.  As a bonus,
 | ||
| <code class="file docutils literal notranslate"><span class="pre">Tools/scripts/pydoc</span></code>, which is now automatically installed, uses
 | ||
| <code class="xref py py-mod docutils literal notranslate"><span class="pre">pydoc.py</span></code> to display documentation given a Python module, package, or
 | ||
| class name.  For example, <code class="docutils literal notranslate"><span class="pre">pydoc</span> <span class="pre">xml.dom</span></code> displays the following:</p>
 | ||
| <div class="highlight-python3 notranslate"><div class="highlight"><pre><span></span><span class="n">Python</span> <span class="n">Library</span> <span class="n">Documentation</span><span class="p">:</span> <span class="n">package</span> <span class="n">xml</span><span class="o">.</span><span class="n">dom</span> <span class="ow">in</span> <span class="n">xml</span>
 | ||
| 
 | ||
| <span class="n">NAME</span>
 | ||
|     <span class="n">xml</span><span class="o">.</span><span class="n">dom</span> <span class="o">-</span> <span class="n">W3C</span> <span class="n">Document</span> <span class="n">Object</span> <span class="n">Model</span> <span class="n">implementation</span> <span class="k">for</span> <span class="n">Python</span><span class="o">.</span>
 | ||
| 
 | ||
| <span class="n">FILE</span>
 | ||
|     <span class="o">/</span><span class="n">usr</span><span class="o">/</span><span class="n">local</span><span class="o">/</span><span class="n">lib</span><span class="o">/</span><span class="n">python2</span><span class="mf">.1</span><span class="o">/</span><span class="n">xml</span><span class="o">/</span><span class="n">dom</span><span class="o">/</span><span class="fm">__init__</span><span class="o">.</span><span class="n">pyc</span>
 | ||
| 
 | ||
| <span class="n">DESCRIPTION</span>
 | ||
|     <span class="n">The</span> <span class="n">Python</span> <span class="n">mapping</span> <span class="n">of</span> <span class="n">the</span> <span class="n">Document</span> <span class="n">Object</span> <span class="n">Model</span> <span class="ow">is</span> <span class="n">documented</span> <span class="ow">in</span> <span class="n">the</span>
 | ||
|     <span class="n">Python</span> <span class="n">Library</span> <span class="n">Reference</span> <span class="ow">in</span> <span class="n">the</span> <span class="n">section</span> <span class="n">on</span> <span class="n">the</span> <span class="n">xml</span><span class="o">.</span><span class="n">dom</span> <span class="n">package</span><span class="o">.</span>
 | ||
| 
 | ||
|     <span class="n">This</span> <span class="n">package</span> <span class="n">contains</span> <span class="n">the</span> <span class="n">following</span> <span class="n">modules</span><span class="p">:</span>
 | ||
|       <span class="o">...</span>
 | ||
| </pre></div>
 | ||
| </div>
 | ||
| <p><code class="file docutils literal notranslate"><span class="pre">pydoc</span></code> also includes a Tk-based interactive help browser.   <code class="file docutils literal notranslate"><span class="pre">pydoc</span></code>
 | ||
| quickly becomes addictive; try it out!</p>
 | ||
| </li>
 | ||
| <li><p>Two different modules for unit testing were added to the standard library.
 | ||
| The <a class="reference internal" href="../library/doctest.html#module-doctest" title="doctest: Test pieces of code within docstrings."><code class="xref py py-mod docutils literal notranslate"><span class="pre">doctest</span></code></a> module, contributed by Tim Peters, provides a testing
 | ||
| framework based on running embedded examples in docstrings and comparing the
 | ||
| results against the expected output.  PyUnit, contributed by Steve Purcell, is a
 | ||
| unit testing framework inspired by JUnit, which was in turn an adaptation of
 | ||
| Kent Beck’s Smalltalk testing framework.  See <a class="reference external" href="https://pyunit.sourceforge.net/">https://pyunit.sourceforge.net/</a> for
 | ||
| more information about PyUnit.</p></li>
 | ||
| <li><p>The <a class="reference internal" href="../library/difflib.html#module-difflib" title="difflib: Helpers for computing differences between objects."><code class="xref py py-mod docutils literal notranslate"><span class="pre">difflib</span></code></a> module contains a class, <a class="reference internal" href="../library/difflib.html#difflib.SequenceMatcher" title="difflib.SequenceMatcher"><code class="xref py py-class docutils literal notranslate"><span class="pre">SequenceMatcher</span></code></a>, which
 | ||
| compares two sequences and computes the changes required to transform one
 | ||
| sequence into the other.  For example, this module can be used to write a tool
 | ||
| similar to the Unix <strong class="program">diff</strong> program, and in fact the sample program
 | ||
| <code class="file docutils literal notranslate"><span class="pre">Tools/scripts/ndiff.py</span></code> demonstrates how to write such a script.</p></li>
 | ||
| <li><p><a class="reference internal" href="../library/curses.panel.html#module-curses.panel" title="curses.panel: A panel stack extension that adds depth to  curses windows."><code class="xref py py-mod docutils literal notranslate"><span class="pre">curses.panel</span></code></a>, a wrapper for the panel library, part of ncurses and of
 | ||
| SYSV curses, was contributed by Thomas Gellekum.  The panel library provides
 | ||
| windows with the additional feature of depth. Windows can be moved higher or
 | ||
| lower in the depth ordering, and the panel library figures out where panels
 | ||
| overlap and which sections are visible.</p></li>
 | ||
| <li><p>The PyXML package has gone through a few releases since Python 2.0, and Python
 | ||
| 2.1 includes an updated version of the <a class="reference internal" href="../library/xml.html#module-xml" title="xml: Package containing XML processing modules"><code class="xref py py-mod docutils literal notranslate"><span class="pre">xml</span></code></a> package.  Some of the
 | ||
| noteworthy changes include support for Expat 1.2 and later versions, the ability
 | ||
| for Expat parsers to handle files in any encoding supported by Python, and
 | ||
| various bugfixes for SAX, DOM, and the <code class="xref py py-mod docutils literal notranslate"><span class="pre">minidom</span></code> module.</p></li>
 | ||
| <li><p>Ping also contributed another hook for handling uncaught exceptions.
 | ||
| <a class="reference internal" href="../library/sys.html#sys.excepthook" title="sys.excepthook"><code class="xref py py-func docutils literal notranslate"><span class="pre">sys.excepthook()</span></code></a> can be set to a callable object.  When an exception isn’t
 | ||
| caught by any <a class="reference internal" href="../reference/compound_stmts.html#try"><code class="xref std std-keyword docutils literal notranslate"><span class="pre">try</span></code></a>…<a class="reference internal" href="../reference/compound_stmts.html#except"><code class="xref std std-keyword docutils literal notranslate"><span class="pre">except</span></code></a> blocks, the exception will be
 | ||
| passed to <a class="reference internal" href="../library/sys.html#sys.excepthook" title="sys.excepthook"><code class="xref py py-func docutils literal notranslate"><span class="pre">sys.excepthook()</span></code></a>, which can then do whatever it likes.  At the
 | ||
| Ninth Python Conference, Ping demonstrated an application for this hook:
 | ||
| printing an extended traceback that not only lists the stack frames, but also
 | ||
| lists the function arguments and the local variables for each frame.</p></li>
 | ||
| <li><p>Various functions in the <a class="reference internal" href="../library/time.html#module-time" title="time: Time access and conversions."><code class="xref py py-mod docutils literal notranslate"><span class="pre">time</span></code></a> module, such as <a class="reference internal" href="../library/time.html#time.asctime" title="time.asctime"><code class="xref py py-func docutils literal notranslate"><span class="pre">asctime()</span></code></a> and
 | ||
| <a class="reference internal" href="../library/time.html#time.localtime" title="time.localtime"><code class="xref py py-func docutils literal notranslate"><span class="pre">localtime()</span></code></a>, require a floating-point argument containing the time in
 | ||
| seconds since the epoch.  The most common use of these functions is to work with
 | ||
| the current time, so the floating-point argument has been made optional; when a
 | ||
| value isn’t provided, the current time will be used.  For example, log file
 | ||
| entries usually need a string containing the current time; in Python 2.1,
 | ||
| <code class="docutils literal notranslate"><span class="pre">time.asctime()</span></code> can be used, instead of the lengthier
 | ||
| <code class="docutils literal notranslate"><span class="pre">time.asctime(time.localtime(time.time()))</span></code> that was previously required.</p>
 | ||
| <p>This change was proposed and implemented by Thomas Wouters.</p>
 | ||
| </li>
 | ||
| <li><p>The <a class="reference internal" href="../library/ftplib.html#module-ftplib" title="ftplib: FTP protocol client (requires sockets)."><code class="xref py py-mod docutils literal notranslate"><span class="pre">ftplib</span></code></a> module now defaults to retrieving files in passive mode,
 | ||
| because passive mode is more likely to work from behind a firewall.  This
 | ||
| request came from the Debian bug tracking system, since other Debian packages
 | ||
| use <a class="reference internal" href="../library/ftplib.html#module-ftplib" title="ftplib: FTP protocol client (requires sockets)."><code class="xref py py-mod docutils literal notranslate"><span class="pre">ftplib</span></code></a> to retrieve files and then don’t work from behind a firewall.
 | ||
| It’s deemed unlikely that this will cause problems for anyone, because Netscape
 | ||
| defaults to passive mode and few people complain, but if passive mode is
 | ||
| unsuitable for your application or network setup, call <code class="docutils literal notranslate"><span class="pre">set_pasv(0)</span></code> on
 | ||
| FTP objects to disable passive mode.</p></li>
 | ||
| <li><p>Support for raw socket access has been added to the <a class="reference internal" href="../library/socket.html#module-socket" title="socket: Low-level networking interface."><code class="xref py py-mod docutils literal notranslate"><span class="pre">socket</span></code></a> module,
 | ||
| contributed by Grant Edwards.</p></li>
 | ||
| <li><p>The <a class="reference internal" href="../library/profile.html#module-pstats" title="pstats: Statistics object for use with the profiler."><code class="xref py py-mod docutils literal notranslate"><span class="pre">pstats</span></code></a> module now contains a simple interactive statistics browser
 | ||
| for displaying timing profiles for Python programs, invoked when the module is
 | ||
| run as a script.  Contributed by  Eric S. Raymond.</p></li>
 | ||
| <li><p>A new implementation-dependent function, <code class="docutils literal notranslate"><span class="pre">sys._getframe([depth])</span></code>, has
 | ||
| been added to return a given frame object from the current call stack.
 | ||
| <a class="reference internal" href="../library/sys.html#sys._getframe" title="sys._getframe"><code class="xref py py-func docutils literal notranslate"><span class="pre">sys._getframe()</span></code></a> returns the frame at the top of the call stack;  if the
 | ||
| optional integer argument <em>depth</em> is supplied, the function returns the frame
 | ||
| that is <em>depth</em> calls below the top of the stack.  For example,
 | ||
| <code class="docutils literal notranslate"><span class="pre">sys._getframe(1)</span></code> returns the caller’s frame object.</p>
 | ||
| <p>This function is only present in CPython, not in Jython or the .NET
 | ||
| implementation.  Use it for debugging, and resist the temptation to put it into
 | ||
| production code.</p>
 | ||
| </li>
 | ||
| </ul>
 | ||
| </section>
 | ||
| <section id="other-changes-and-fixes">
 | ||
| <h2>Other Changes and Fixes<a class="headerlink" href="#other-changes-and-fixes" title="Link to this heading">¶</a></h2>
 | ||
| <p>There were relatively few smaller changes made in Python 2.1 due to the shorter
 | ||
| release cycle.  A search through the CVS change logs turns up 117 patches
 | ||
| applied, and 136 bugs fixed; both figures are likely to be underestimates.  Some
 | ||
| of the more notable changes are:</p>
 | ||
| <ul>
 | ||
| <li><p>A specialized object allocator is now optionally available, that should be
 | ||
| faster than the system <code class="xref c c-func docutils literal notranslate"><span class="pre">malloc()</span></code> and have less memory overhead.  The
 | ||
| allocator uses C’s <code class="xref c c-func docutils literal notranslate"><span class="pre">malloc()</span></code> function to get large pools of memory, and
 | ||
| then fulfills smaller memory requests from these pools.  It can be enabled by
 | ||
| providing the <code class="xref std std-option docutils literal notranslate"><span class="pre">--with-pymalloc</span></code> option to the <strong class="program">configure</strong>
 | ||
| script; see <code class="file docutils literal notranslate"><span class="pre">Objects/obmalloc.c</span></code> for the implementation details.</p>
 | ||
| <p>Authors of C extension modules should test their code with the object allocator
 | ||
| enabled, 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 have
 | ||
| previously been just aliases for the C library’s <code class="xref c c-func docutils literal notranslate"><span class="pre">malloc()</span></code> and
 | ||
| <code class="xref c c-func docutils literal notranslate"><span class="pre">free()</span></code>, meaning that if you accidentally called mismatched functions, the
 | ||
| error wouldn’t be noticeable.  When the object allocator is enabled, these
 | ||
| functions aren’t aliases of <code class="xref c c-func docutils literal notranslate"><span class="pre">malloc()</span></code> and <code class="xref c c-func docutils literal notranslate"><span class="pre">free()</span></code> any more, and
 | ||
| calling the wrong function to free memory will get you a core dump.  For
 | ||
| example, if memory was allocated using <a class="reference internal" href="../c-api/memory.html#c.PyMem_New" title="PyMem_New"><code class="xref c c-macro docutils literal notranslate"><span class="pre">PyMem_New</span></code></a>, it has to be freed
 | ||
| using <a class="reference internal" href="../c-api/memory.html#c.PyMem_Del" title="PyMem_Del"><code class="xref c c-func docutils literal notranslate"><span class="pre">PyMem_Del()</span></code></a>, not <code class="xref c c-func docutils literal notranslate"><span class="pre">free()</span></code>.  A few modules included with Python
 | ||
| fell afoul of this and had to be fixed; doubtless there are more third-party
 | ||
| modules that will have the same problem.</p>
 | ||
| <p>The object allocator was contributed by Vladimir Marangozov.</p>
 | ||
| </li>
 | ||
| <li><p>The speed of line-oriented file I/O has been improved because people often
 | ||
| complain about its lack of speed, and because it’s often been used as a naïve
 | ||
| benchmark.  The <a class="reference internal" href="../library/readline.html#module-readline" title="readline: GNU readline support for Python. (Unix)"><code class="xref py py-meth docutils literal notranslate"><span class="pre">readline()</span></code></a> method of file objects has therefore been
 | ||
| rewritten to be much faster.  The exact amount of the speedup will vary from
 | ||
| platform to platform depending on how slow the C library’s <code class="xref c c-func docutils literal notranslate"><span class="pre">getc()</span></code> was, but
 | ||
| is around 66%, and potentially much faster on some particular operating systems.
 | ||
| Tim Peters did much of the benchmarking and coding for this change, motivated by
 | ||
| a discussion in comp.lang.python.</p>
 | ||
| <p>A new module and method for file objects was also added, contributed by Jeff
 | ||
| Epler. The new method, <code class="xref py py-meth docutils literal notranslate"><span class="pre">xreadlines()</span></code>, is similar to the existing
 | ||
| <code class="xref py py-func docutils literal notranslate"><span class="pre">xrange()</span></code> built-in.  <code class="xref py py-func docutils literal notranslate"><span class="pre">xreadlines()</span></code> returns an opaque sequence object
 | ||
| that only supports being iterated over, reading a line on every iteration but
 | ||
| not reading the entire file into memory as the existing <code class="xref py py-meth docutils literal notranslate"><span class="pre">readlines()</span></code> method
 | ||
| does. You’d use it like this:</p>
 | ||
| <div class="highlight-python3 notranslate"><div class="highlight"><pre><span></span><span class="k">for</span> <span class="n">line</span> <span class="ow">in</span> <span class="n">sys</span><span class="o">.</span><span class="n">stdin</span><span class="o">.</span><span class="n">xreadlines</span><span class="p">():</span>
 | ||
|     <span class="c1"># ... do something for each line ...</span>
 | ||
|     <span class="o">...</span>
 | ||
| </pre></div>
 | ||
| </div>
 | ||
| <p>For a fuller discussion of the line I/O changes, see the python-dev summary for
 | ||
| January 1–15, 2001 at <a class="reference external" href="https://mail.python.org/pipermail/python-dev/2001-January/">https://mail.python.org/pipermail/python-dev/2001-January/</a>.</p>
 | ||
| </li>
 | ||
| <li><p>A new method, <a class="reference internal" href="../library/stdtypes.html#dict.popitem" title="dict.popitem"><code class="xref py py-meth docutils literal notranslate"><span class="pre">popitem()</span></code></a>, was added to dictionaries to enable
 | ||
| destructively iterating through the contents of a dictionary; this can be faster
 | ||
| for large dictionaries because there’s no need to construct a list containing
 | ||
| all the keys or values. <code class="docutils literal notranslate"><span class="pre">D.popitem()</span></code> removes a random <code class="docutils literal notranslate"><span class="pre">(key,</span> <span class="pre">value)</span></code> pair
 | ||
| from the dictionary <code class="docutils literal notranslate"><span class="pre">D</span></code> and returns it as a 2-tuple.  This was implemented
 | ||
| mostly by Tim Peters and Guido van Rossum, after a suggestion and preliminary
 | ||
| patch by Moshe Zadka.</p></li>
 | ||
| <li><p>Modules can now control which names are imported when <code class="docutils literal notranslate"><span class="pre">from</span> <span class="pre">module</span> <span class="pre">import</span> <span class="pre">*</span></code>
 | ||
| is used, by defining an <code class="docutils literal notranslate"><span class="pre">__all__</span></code> attribute containing a list of names that
 | ||
| will be imported.  One common complaint is that if the module imports other
 | ||
| modules such as <a class="reference internal" href="../library/sys.html#module-sys" title="sys: Access system-specific parameters and functions."><code class="xref py py-mod docutils literal notranslate"><span class="pre">sys</span></code></a> or <a class="reference internal" href="../library/string.html#module-string" title="string: Common string operations."><code class="xref py py-mod docutils literal notranslate"><span class="pre">string</span></code></a>, <code class="docutils literal notranslate"><span class="pre">from</span> <span class="pre">module</span> <span class="pre">import</span> <span class="pre">*</span></code> will add
 | ||
| them to the importing module’s namespace.  To fix this, simply list the public
 | ||
| names in <code class="docutils literal notranslate"><span class="pre">__all__</span></code>:</p>
 | ||
| <div class="highlight-python3 notranslate"><div class="highlight"><pre><span></span><span class="c1"># List public names</span>
 | ||
| <span class="n">__all__</span> <span class="o">=</span> <span class="p">[</span><span class="s1">'Database'</span><span class="p">,</span> <span class="s1">'open'</span><span class="p">]</span>
 | ||
| </pre></div>
 | ||
| </div>
 | ||
| <p>A stricter version of this patch was first suggested and implemented by Ben
 | ||
| Wolfson, but after some python-dev discussion, a weaker final version was
 | ||
| checked in.</p>
 | ||
| </li>
 | ||
| <li><p>Applying <a class="reference internal" href="../library/functions.html#repr" title="repr"><code class="xref py py-func docutils literal notranslate"><span class="pre">repr()</span></code></a> to strings previously used octal escapes for
 | ||
| non-printable characters; for example, a newline was <code class="docutils literal notranslate"><span class="pre">'\012'</span></code>.  This was a
 | ||
| vestigial trace of Python’s C ancestry, but today octal is of very little
 | ||
| practical use.  Ka-Ping Yee suggested using hex escapes instead of octal ones,
 | ||
| and using the <code class="docutils literal notranslate"><span class="pre">\n</span></code>, <code class="docutils literal notranslate"><span class="pre">\t</span></code>, <code class="docutils literal notranslate"><span class="pre">\r</span></code> escapes for the appropriate characters,
 | ||
| and implemented this new formatting.</p></li>
 | ||
| <li><p>Syntax errors detected at compile-time can now raise exceptions containing the
 | ||
| filename and line number of the error, a pleasant side effect of the compiler
 | ||
| reorganization done by Jeremy Hylton.</p></li>
 | ||
| <li><p>C extensions which import other modules have been changed to use
 | ||
| <a class="reference internal" href="../c-api/import.html#c.PyImport_ImportModule" title="PyImport_ImportModule"><code class="xref c c-func docutils literal notranslate"><span class="pre">PyImport_ImportModule()</span></code></a>, which means that they will use any import hooks
 | ||
| that have been installed.  This is also encouraged for third-party extensions
 | ||
| that need to import some other module from C code.</p></li>
 | ||
| <li><p>The size of the Unicode character database was shrunk by another 340K thanks
 | ||
| to Fredrik Lundh.</p></li>
 | ||
| <li><p>Some new ports were contributed: MacOS X (by Steven Majewski), Cygwin (by
 | ||
| Jason Tishler); RISCOS (by Dietmar Schwertberger); Unixware 7  (by Billy G.
 | ||
| Allie).</p></li>
 | ||
| </ul>
 | ||
| <p>And there’s the usual list of minor bugfixes, minor memory leaks, docstring
 | ||
| edits, and other tweaks, too lengthy to be worth itemizing; see the CVS logs for
 | ||
| the full details if you want them.</p>
 | ||
| </section>
 | ||
| <section id="acknowledgements">
 | ||
| <h2>Acknowledgements<a class="headerlink" href="#acknowledgements" title="Link to this heading">¶</a></h2>
 | ||
| <p>The author would like to thank the following people for offering suggestions on
 | ||
| various drafts of this article: Graeme Cross, David Goodger, Jay Graves, Michael
 | ||
| Hudson, Marc-André Lemburg, Fredrik Lundh, Neil Schemenauer, Thomas Wouters.</p>
 | ||
| </section>
 | ||
| </section>
 | ||
| 
 | ||
| 
 | ||
|             <div class="clearer"></div>
 | ||
|           </div>
 | ||
|         </div>
 | ||
|       </div>
 | ||
|       <div class="sphinxsidebar" role="navigation" aria-label="Main">
 | ||
|         <div class="sphinxsidebarwrapper">
 | ||
|   <div>
 | ||
|     <h3><a href="../contents.html">Table of Contents</a></h3>
 | ||
|     <ul>
 | ||
| <li><a class="reference internal" href="#">What’s New in Python 2.1</a><ul>
 | ||
| <li><a class="reference internal" href="#introduction">Introduction</a></li>
 | ||
| <li><a class="reference internal" href="#pep-227-nested-scopes">PEP 227: Nested Scopes</a></li>
 | ||
| <li><a class="reference internal" href="#pep-236-future-directives">PEP 236: __future__ Directives</a></li>
 | ||
| <li><a class="reference internal" href="#pep-207-rich-comparisons">PEP 207: Rich Comparisons</a></li>
 | ||
| <li><a class="reference internal" href="#pep-230-warning-framework">PEP 230: Warning Framework</a></li>
 | ||
| <li><a class="reference internal" href="#pep-229-new-build-system">PEP 229: New Build System</a></li>
 | ||
| <li><a class="reference internal" href="#pep-205-weak-references">PEP 205: Weak References</a></li>
 | ||
| <li><a class="reference internal" href="#pep-232-function-attributes">PEP 232: Function Attributes</a></li>
 | ||
| <li><a class="reference internal" href="#pep-235-importing-modules-on-case-insensitive-platforms">PEP 235: Importing Modules on Case-Insensitive Platforms</a></li>
 | ||
| <li><a class="reference internal" href="#pep-217-interactive-display-hook">PEP 217: Interactive Display Hook</a></li>
 | ||
| <li><a class="reference internal" href="#pep-208-new-coercion-model">PEP 208: New Coercion Model</a></li>
 | ||
| <li><a class="reference internal" href="#pep-241-metadata-in-python-packages">PEP 241: Metadata in Python Packages</a></li>
 | ||
| <li><a class="reference internal" href="#new-and-improved-modules">New and Improved Modules</a></li>
 | ||
| <li><a class="reference internal" href="#other-changes-and-fixes">Other Changes and Fixes</a></li>
 | ||
| <li><a class="reference internal" href="#acknowledgements">Acknowledgements</a></li>
 | ||
| </ul>
 | ||
| </li>
 | ||
| </ul>
 | ||
| 
 | ||
|   </div>
 | ||
|   <div>
 | ||
|     <h4>Previous topic</h4>
 | ||
|     <p class="topless"><a href="2.2.html"
 | ||
|                           title="previous chapter">What’s New in Python 2.2</a></p>
 | ||
|   </div>
 | ||
|   <div>
 | ||
|     <h4>Next topic</h4>
 | ||
|     <p class="topless"><a href="2.0.html"
 | ||
|                           title="next chapter">What’s New in Python 2.0</a></p>
 | ||
|   </div>
 | ||
|   <div role="note" aria-label="source link">
 | ||
|     <h3>This Page</h3>
 | ||
|     <ul class="this-page-menu">
 | ||
|       <li><a href="../bugs.html">Report a Bug</a></li>
 | ||
|       <li>
 | ||
|         <a href="https://github.com/python/cpython/blob/main/Doc/whatsnew/2.1.rst"
 | ||
|             rel="nofollow">Show Source
 | ||
|         </a>
 | ||
|       </li>
 | ||
|     </ul>
 | ||
|   </div>
 | ||
|         </div>
 | ||
| <div id="sidebarbutton" title="Collapse sidebar">
 | ||
| <span>«</span>
 | ||
| </div>
 | ||
| 
 | ||
|       </div>
 | ||
|       <div class="clearer"></div>
 | ||
|     </div>  
 | ||
|     <div class="related" role="navigation" aria-label="Related">
 | ||
|       <h3>Navigation</h3>
 | ||
|       <ul>
 | ||
|         <li class="right" style="margin-right: 10px">
 | ||
|           <a href="../genindex.html" title="General Index"
 | ||
|              >index</a></li>
 | ||
|         <li class="right" >
 | ||
|           <a href="../py-modindex.html" title="Python Module Index"
 | ||
|              >modules</a> |</li>
 | ||
|         <li class="right" >
 | ||
|           <a href="2.0.html" title="What’s New in Python 2.0"
 | ||
|              >next</a> |</li>
 | ||
|         <li class="right" >
 | ||
|           <a href="2.2.html" title="What’s New in Python 2.2"
 | ||
|              >previous</a> |</li>
 | ||
| 
 | ||
|           <li><img src="../_static/py.svg" alt="Python logo" style="vertical-align: middle; margin-top: -1px"/></li>
 | ||
|           <li><a href="https://www.python.org/">Python</a> »</li>
 | ||
|           <li class="switchers">
 | ||
|             <div class="language_switcher_placeholder"></div>
 | ||
|             <div class="version_switcher_placeholder"></div>
 | ||
|           </li>
 | ||
|           <li>
 | ||
|               
 | ||
|           </li>
 | ||
|     <li id="cpython-language-and-version">
 | ||
|       <a href="../index.html">3.13.3 Documentation</a> »
 | ||
|     </li>
 | ||
| 
 | ||
|           <li class="nav-item nav-item-1"><a href="index.html" >What’s New in Python</a> »</li>
 | ||
|         <li class="nav-item nav-item-this"><a href="">What’s New in Python 2.1</a></li>
 | ||
|                 <li class="right">
 | ||
|                     
 | ||
| 
 | ||
|     <div class="inline-search" role="search">
 | ||
|         <form class="inline-search" action="../search.html" method="get">
 | ||
|           <input placeholder="Quick search" aria-label="Quick search" type="search" name="q" id="search-box" />
 | ||
|           <input type="submit" value="Go" />
 | ||
|         </form>
 | ||
|     </div>
 | ||
|                      |
 | ||
|                 </li>
 | ||
|             <li class="right">
 | ||
| <label class="theme-selector-label">
 | ||
|     Theme
 | ||
|     <select class="theme-selector" oninput="activateTheme(this.value)">
 | ||
|         <option value="auto" selected>Auto</option>
 | ||
|         <option value="light">Light</option>
 | ||
|         <option value="dark">Dark</option>
 | ||
|     </select>
 | ||
| </label> |</li>
 | ||
|             
 | ||
|       </ul>
 | ||
|     </div>  
 | ||
|     <div class="footer">
 | ||
|     © 
 | ||
|       <a href="../copyright.html">
 | ||
|     
 | ||
|     Copyright
 | ||
|     
 | ||
|       </a>
 | ||
|      2001-2025, Python Software Foundation.
 | ||
|     <br />
 | ||
|     This page is licensed under the Python Software Foundation License Version 2.
 | ||
|     <br />
 | ||
|     Examples, recipes, and other code in the documentation are additionally licensed under the Zero Clause BSD License.
 | ||
|     <br />
 | ||
|     
 | ||
|       See <a href="/license.html">History and License</a> for more information.<br />
 | ||
|     
 | ||
|     
 | ||
|     <br />
 | ||
| 
 | ||
|     The Python Software Foundation is a non-profit corporation.
 | ||
| <a href="https://www.python.org/psf/donations/">Please donate.</a>
 | ||
| <br />
 | ||
|     <br />
 | ||
|       Last updated on Apr 08, 2025 (14:33 UTC).
 | ||
|     
 | ||
|       <a href="/bugs.html">Found a bug</a>?
 | ||
|     
 | ||
|     <br />
 | ||
| 
 | ||
|     Created using <a href="https://www.sphinx-doc.org/">Sphinx</a> 8.2.3.
 | ||
|     </div>
 | ||
| 
 | ||
|   </body>
 | ||
| </html> |