938 lines
82 KiB
HTML
938 lines
82 KiB
HTML
|
||
<!DOCTYPE html>
|
||
|
||
<html xmlns="http://www.w3.org/1999/xhtml">
|
||
<head>
|
||
<meta charset="utf-8" />
|
||
<title>Design and History FAQ — Python 3.7.4 documentation</title>
|
||
<link rel="stylesheet" href="../_static/pydoctheme.css" type="text/css" />
|
||
<link rel="stylesheet" href="../_static/pygments.css" type="text/css" />
|
||
|
||
<script type="text/javascript" id="documentation_options" data-url_root="../" src="../_static/documentation_options.js"></script>
|
||
<script type="text/javascript" src="../_static/jquery.js"></script>
|
||
<script type="text/javascript" src="../_static/underscore.js"></script>
|
||
<script type="text/javascript" src="../_static/doctools.js"></script>
|
||
<script type="text/javascript" src="../_static/language_data.js"></script>
|
||
|
||
<script type="text/javascript" src="../_static/sidebar.js"></script>
|
||
|
||
<link rel="search" type="application/opensearchdescription+xml"
|
||
title="Search within Python 3.7.4 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="Library and Extension FAQ" href="library.html" />
|
||
<link rel="prev" title="Programming FAQ" href="programming.html" />
|
||
<link rel="shortcut icon" type="image/png" href="../_static/py.png" />
|
||
<link rel="canonical" href="https://docs.python.org/3/faq/design.html" />
|
||
|
||
<script type="text/javascript" src="../_static/copybutton.js"></script>
|
||
<script type="text/javascript" src="../_static/switchers.js"></script>
|
||
|
||
|
||
|
||
<style>
|
||
@media only screen {
|
||
table.full-width-table {
|
||
width: 100%;
|
||
}
|
||
}
|
||
</style>
|
||
|
||
|
||
</head><body>
|
||
|
||
<div class="related" role="navigation" aria-label="related navigation">
|
||
<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="library.html" title="Library and Extension FAQ"
|
||
accesskey="N">next</a> |</li>
|
||
<li class="right" >
|
||
<a href="programming.html" title="Programming FAQ"
|
||
accesskey="P">previous</a> |</li>
|
||
<li><img src="../_static/py.png" alt=""
|
||
style="vertical-align: middle; margin-top: -1px"/></li>
|
||
<li><a href="https://www.python.org/">Python</a> »</li>
|
||
<li>
|
||
<span class="language_switcher_placeholder">en</span>
|
||
<span class="version_switcher_placeholder">3.7.4</span>
|
||
<a href="../index.html">Documentation </a> »
|
||
</li>
|
||
|
||
<li class="nav-item nav-item-1"><a href="index.html" accesskey="U">Python Frequently Asked Questions</a> »</li>
|
||
<li class="right">
|
||
|
||
|
||
<div class="inline-search" style="display: none" role="search">
|
||
<form class="inline-search" action="../search.html" method="get">
|
||
<input placeholder="Quick search" type="text" name="q" />
|
||
<input type="submit" value="Go" />
|
||
<input type="hidden" name="check_keywords" value="yes" />
|
||
<input type="hidden" name="area" value="default" />
|
||
</form>
|
||
</div>
|
||
<script type="text/javascript">$('.inline-search').show(0);</script>
|
||
|
|
||
</li>
|
||
|
||
</ul>
|
||
</div>
|
||
|
||
<div class="document">
|
||
<div class="documentwrapper">
|
||
<div class="bodywrapper">
|
||
<div class="body" role="main">
|
||
|
||
<div class="section" id="design-and-history-faq">
|
||
<h1><a class="toc-backref" href="#id1">Design and History FAQ</a><a class="headerlink" href="#design-and-history-faq" title="Permalink to this headline">¶</a></h1>
|
||
<div class="contents topic" id="contents">
|
||
<p class="topic-title first">Contents</p>
|
||
<ul class="simple">
|
||
<li><p><a class="reference internal" href="#design-and-history-faq" id="id1">Design and History FAQ</a></p>
|
||
<ul>
|
||
<li><p><a class="reference internal" href="#why-does-python-use-indentation-for-grouping-of-statements" id="id2">Why does Python use indentation for grouping of statements?</a></p></li>
|
||
<li><p><a class="reference internal" href="#why-am-i-getting-strange-results-with-simple-arithmetic-operations" id="id3">Why am I getting strange results with simple arithmetic operations?</a></p></li>
|
||
<li><p><a class="reference internal" href="#why-are-floating-point-calculations-so-inaccurate" id="id4">Why are floating-point calculations so inaccurate?</a></p></li>
|
||
<li><p><a class="reference internal" href="#why-are-python-strings-immutable" id="id5">Why are Python strings immutable?</a></p></li>
|
||
<li><p><a class="reference internal" href="#why-must-self-be-used-explicitly-in-method-definitions-and-calls" id="id6">Why must ‘self’ be used explicitly in method definitions and calls?</a></p></li>
|
||
<li><p><a class="reference internal" href="#why-can-t-i-use-an-assignment-in-an-expression" id="id7">Why can’t I use an assignment in an expression?</a></p></li>
|
||
<li><p><a class="reference internal" href="#why-does-python-use-methods-for-some-functionality-e-g-list-index-but-functions-for-other-e-g-len-list" id="id8">Why does Python use methods for some functionality (e.g. list.index()) but functions for other (e.g. len(list))?</a></p></li>
|
||
<li><p><a class="reference internal" href="#why-is-join-a-string-method-instead-of-a-list-or-tuple-method" id="id9">Why is join() a string method instead of a list or tuple method?</a></p></li>
|
||
<li><p><a class="reference internal" href="#how-fast-are-exceptions" id="id10">How fast are exceptions?</a></p></li>
|
||
<li><p><a class="reference internal" href="#why-isn-t-there-a-switch-or-case-statement-in-python" id="id11">Why isn’t there a switch or case statement in Python?</a></p></li>
|
||
<li><p><a class="reference internal" href="#can-t-you-emulate-threads-in-the-interpreter-instead-of-relying-on-an-os-specific-thread-implementation" id="id12">Can’t you emulate threads in the interpreter instead of relying on an OS-specific thread implementation?</a></p></li>
|
||
<li><p><a class="reference internal" href="#why-can-t-lambda-expressions-contain-statements" id="id13">Why can’t lambda expressions contain statements?</a></p></li>
|
||
<li><p><a class="reference internal" href="#can-python-be-compiled-to-machine-code-c-or-some-other-language" id="id14">Can Python be compiled to machine code, C or some other language?</a></p></li>
|
||
<li><p><a class="reference internal" href="#how-does-python-manage-memory" id="id15">How does Python manage memory?</a></p></li>
|
||
<li><p><a class="reference internal" href="#why-doesn-t-cpython-use-a-more-traditional-garbage-collection-scheme" id="id16">Why doesn’t CPython use a more traditional garbage collection scheme?</a></p></li>
|
||
<li><p><a class="reference internal" href="#why-isn-t-all-memory-freed-when-cpython-exits" id="id17">Why isn’t all memory freed when CPython exits?</a></p></li>
|
||
<li><p><a class="reference internal" href="#why-are-there-separate-tuple-and-list-data-types" id="id18">Why are there separate tuple and list data types?</a></p></li>
|
||
<li><p><a class="reference internal" href="#how-are-lists-implemented-in-cpython" id="id19">How are lists implemented in CPython?</a></p></li>
|
||
<li><p><a class="reference internal" href="#how-are-dictionaries-implemented-in-cpython" id="id20">How are dictionaries implemented in CPython?</a></p></li>
|
||
<li><p><a class="reference internal" href="#why-must-dictionary-keys-be-immutable" id="id21">Why must dictionary keys be immutable?</a></p></li>
|
||
<li><p><a class="reference internal" href="#why-doesn-t-list-sort-return-the-sorted-list" id="id22">Why doesn’t list.sort() return the sorted list?</a></p></li>
|
||
<li><p><a class="reference internal" href="#how-do-you-specify-and-enforce-an-interface-spec-in-python" id="id23">How do you specify and enforce an interface spec in Python?</a></p></li>
|
||
<li><p><a class="reference internal" href="#why-is-there-no-goto" id="id24">Why is there no goto?</a></p></li>
|
||
<li><p><a class="reference internal" href="#why-can-t-raw-strings-r-strings-end-with-a-backslash" id="id25">Why can’t raw strings (r-strings) end with a backslash?</a></p></li>
|
||
<li><p><a class="reference internal" href="#why-doesn-t-python-have-a-with-statement-for-attribute-assignments" id="id26">Why doesn’t Python have a “with” statement for attribute assignments?</a></p></li>
|
||
<li><p><a class="reference internal" href="#why-are-colons-required-for-the-if-while-def-class-statements" id="id27">Why are colons required for the if/while/def/class statements?</a></p></li>
|
||
<li><p><a class="reference internal" href="#why-does-python-allow-commas-at-the-end-of-lists-and-tuples" id="id28">Why does Python allow commas at the end of lists and tuples?</a></p></li>
|
||
</ul>
|
||
</li>
|
||
</ul>
|
||
</div>
|
||
<div class="section" id="why-does-python-use-indentation-for-grouping-of-statements">
|
||
<h2><a class="toc-backref" href="#id2">Why does Python use indentation for grouping of statements?</a><a class="headerlink" href="#why-does-python-use-indentation-for-grouping-of-statements" title="Permalink to this headline">¶</a></h2>
|
||
<p>Guido van Rossum believes that using indentation for grouping is extremely
|
||
elegant and contributes a lot to the clarity of the average Python program.
|
||
Most people learn to love this feature after a while.</p>
|
||
<p>Since there are no begin/end brackets there cannot be a disagreement between
|
||
grouping perceived by the parser and the human reader. Occasionally C
|
||
programmers will encounter a fragment of code like this:</p>
|
||
<div class="highlight-python3 notranslate"><div class="highlight"><pre><span></span><span class="k">if</span> <span class="p">(</span><span class="n">x</span> <span class="o"><=</span> <span class="n">y</span><span class="p">)</span>
|
||
<span class="n">x</span><span class="o">++</span><span class="p">;</span>
|
||
<span class="n">y</span><span class="o">--</span><span class="p">;</span>
|
||
<span class="n">z</span><span class="o">++</span><span class="p">;</span>
|
||
</pre></div>
|
||
</div>
|
||
<p>Only the <code class="docutils literal notranslate"><span class="pre">x++</span></code> statement is executed if the condition is true, but the
|
||
indentation leads you to believe otherwise. Even experienced C programmers will
|
||
sometimes stare at it a long time wondering why <code class="docutils literal notranslate"><span class="pre">y</span></code> is being decremented even
|
||
for <code class="docutils literal notranslate"><span class="pre">x</span> <span class="pre">></span> <span class="pre">y</span></code>.</p>
|
||
<p>Because there are no begin/end brackets, Python is much less prone to
|
||
coding-style conflicts. In C there are many different ways to place the braces.
|
||
If you’re used to reading and writing code that uses one style, you will feel at
|
||
least slightly uneasy when reading (or being required to write) another style.</p>
|
||
<p>Many coding styles place begin/end brackets on a line by themselves. This makes
|
||
programs considerably longer and wastes valuable screen space, making it harder
|
||
to get a good overview of a program. Ideally, a function should fit on one
|
||
screen (say, 20–30 lines). 20 lines of Python can do a lot more work than 20
|
||
lines of C. This is not solely due to the lack of begin/end brackets – the
|
||
lack of declarations and the high-level data types are also responsible – but
|
||
the indentation-based syntax certainly helps.</p>
|
||
</div>
|
||
<div class="section" id="why-am-i-getting-strange-results-with-simple-arithmetic-operations">
|
||
<h2><a class="toc-backref" href="#id3">Why am I getting strange results with simple arithmetic operations?</a><a class="headerlink" href="#why-am-i-getting-strange-results-with-simple-arithmetic-operations" title="Permalink to this headline">¶</a></h2>
|
||
<p>See the next question.</p>
|
||
</div>
|
||
<div class="section" id="why-are-floating-point-calculations-so-inaccurate">
|
||
<h2><a class="toc-backref" href="#id4">Why are floating-point calculations so inaccurate?</a><a class="headerlink" href="#why-are-floating-point-calculations-so-inaccurate" title="Permalink to this headline">¶</a></h2>
|
||
<p>Users are often surprised by results like this:</p>
|
||
<div class="highlight-python3 notranslate"><div class="highlight"><pre><span></span><span class="gp">>>> </span><span class="mf">1.2</span> <span class="o">-</span> <span class="mf">1.0</span>
|
||
<span class="go">0.19999999999999996</span>
|
||
</pre></div>
|
||
</div>
|
||
<p>and think it is a bug in Python. It’s not. This has little to do with Python,
|
||
and much more to do with how the underlying platform handles floating-point
|
||
numbers.</p>
|
||
<p>The <a class="reference internal" href="../library/functions.html#float" title="float"><code class="xref py py-class docutils literal notranslate"><span class="pre">float</span></code></a> type in CPython uses a C <code class="docutils literal notranslate"><span class="pre">double</span></code> for storage. A
|
||
<a class="reference internal" href="../library/functions.html#float" title="float"><code class="xref py py-class docutils literal notranslate"><span class="pre">float</span></code></a> object’s value is stored in binary floating-point with a fixed
|
||
precision (typically 53 bits) and Python uses C operations, which in turn rely
|
||
on the hardware implementation in the processor, to perform floating-point
|
||
operations. This means that as far as floating-point operations are concerned,
|
||
Python behaves like many popular languages including C and Java.</p>
|
||
<p>Many numbers that can be written easily in decimal notation cannot be expressed
|
||
exactly in binary floating-point. For example, after:</p>
|
||
<div class="highlight-python3 notranslate"><div class="highlight"><pre><span></span><span class="gp">>>> </span><span class="n">x</span> <span class="o">=</span> <span class="mf">1.2</span>
|
||
</pre></div>
|
||
</div>
|
||
<p>the value stored for <code class="docutils literal notranslate"><span class="pre">x</span></code> is a (very good) approximation to the decimal value
|
||
<code class="docutils literal notranslate"><span class="pre">1.2</span></code>, but is not exactly equal to it. On a typical machine, the actual
|
||
stored value is:</p>
|
||
<div class="highlight-python3 notranslate"><div class="highlight"><pre><span></span><span class="mf">1.0011001100110011001100110011001100110011001100110011</span> <span class="p">(</span><span class="n">binary</span><span class="p">)</span>
|
||
</pre></div>
|
||
</div>
|
||
<p>which is exactly:</p>
|
||
<div class="highlight-python3 notranslate"><div class="highlight"><pre><span></span><span class="mf">1.1999999999999999555910790149937383830547332763671875</span> <span class="p">(</span><span class="n">decimal</span><span class="p">)</span>
|
||
</pre></div>
|
||
</div>
|
||
<p>The typical precision of 53 bits provides Python floats with 15–16
|
||
decimal digits of accuracy.</p>
|
||
<p>For a fuller explanation, please see the <a class="reference internal" href="../tutorial/floatingpoint.html#tut-fp-issues"><span class="std std-ref">floating point arithmetic</span></a> chapter in the Python tutorial.</p>
|
||
</div>
|
||
<div class="section" id="why-are-python-strings-immutable">
|
||
<h2><a class="toc-backref" href="#id5">Why are Python strings immutable?</a><a class="headerlink" href="#why-are-python-strings-immutable" title="Permalink to this headline">¶</a></h2>
|
||
<p>There are several advantages.</p>
|
||
<p>One is performance: knowing that a string is immutable means we can allocate
|
||
space for it at creation time, and the storage requirements are fixed and
|
||
unchanging. This is also one of the reasons for the distinction between tuples
|
||
and lists.</p>
|
||
<p>Another advantage is that strings in Python are considered as “elemental” as
|
||
numbers. No amount of activity will change the value 8 to anything else, and in
|
||
Python, no amount of activity will change the string “eight” to anything else.</p>
|
||
</div>
|
||
<div class="section" id="why-must-self-be-used-explicitly-in-method-definitions-and-calls">
|
||
<span id="why-self"></span><h2><a class="toc-backref" href="#id6">Why must ‘self’ be used explicitly in method definitions and calls?</a><a class="headerlink" href="#why-must-self-be-used-explicitly-in-method-definitions-and-calls" title="Permalink to this headline">¶</a></h2>
|
||
<p>The idea was borrowed from Modula-3. It turns out to be very useful, for a
|
||
variety of reasons.</p>
|
||
<p>First, it’s more obvious that you are using a method or instance attribute
|
||
instead of a local variable. Reading <code class="docutils literal notranslate"><span class="pre">self.x</span></code> or <code class="docutils literal notranslate"><span class="pre">self.meth()</span></code> makes it
|
||
absolutely clear that an instance variable or method is used even if you don’t
|
||
know the class definition by heart. In C++, you can sort of tell by the lack of
|
||
a local variable declaration (assuming globals are rare or easily recognizable)
|
||
– but in Python, there are no local variable declarations, so you’d have to
|
||
look up the class definition to be sure. Some C++ and Java coding standards
|
||
call for instance attributes to have an <code class="docutils literal notranslate"><span class="pre">m_</span></code> prefix, so this explicitness is
|
||
still useful in those languages, too.</p>
|
||
<p>Second, it means that no special syntax is necessary if you want to explicitly
|
||
reference or call the method from a particular class. In C++, if you want to
|
||
use a method from a base class which is overridden in a derived class, you have
|
||
to use the <code class="docutils literal notranslate"><span class="pre">::</span></code> operator – in Python you can write
|
||
<code class="docutils literal notranslate"><span class="pre">baseclass.methodname(self,</span> <span class="pre"><argument</span> <span class="pre">list>)</span></code>. This is particularly useful
|
||
for <a class="reference internal" href="../reference/datamodel.html#object.__init__" title="object.__init__"><code class="xref py py-meth docutils literal notranslate"><span class="pre">__init__()</span></code></a> methods, and in general in cases where a derived class
|
||
method wants to extend the base class method of the same name and thus has to
|
||
call the base class method somehow.</p>
|
||
<p>Finally, for instance variables it solves a syntactic problem with assignment:
|
||
since local variables in Python are (by definition!) those variables to which a
|
||
value is assigned in a function body (and that aren’t explicitly declared
|
||
global), there has to be some way to tell the interpreter that an assignment was
|
||
meant to assign to an instance variable instead of to a local variable, and it
|
||
should preferably be syntactic (for efficiency reasons). C++ does this through
|
||
declarations, but Python doesn’t have declarations and it would be a pity having
|
||
to introduce them just for this purpose. Using the explicit <code class="docutils literal notranslate"><span class="pre">self.var</span></code> solves
|
||
this nicely. Similarly, for using instance variables, having to write
|
||
<code class="docutils literal notranslate"><span class="pre">self.var</span></code> means that references to unqualified names inside a method don’t
|
||
have to search the instance’s directories. To put it another way, local
|
||
variables and instance variables live in two different namespaces, and you need
|
||
to tell Python which namespace to use.</p>
|
||
</div>
|
||
<div class="section" id="why-can-t-i-use-an-assignment-in-an-expression">
|
||
<h2><a class="toc-backref" href="#id7">Why can’t I use an assignment in an expression?</a><a class="headerlink" href="#why-can-t-i-use-an-assignment-in-an-expression" title="Permalink to this headline">¶</a></h2>
|
||
<p>Many people used to C or Perl complain that they want to use this C idiom:</p>
|
||
<div class="highlight-c notranslate"><div class="highlight"><pre><span></span><span class="k">while</span> <span class="p">(</span><span class="n">line</span> <span class="o">=</span> <span class="n">readline</span><span class="p">(</span><span class="n">f</span><span class="p">))</span> <span class="p">{</span>
|
||
<span class="c1">// do something with line</span>
|
||
<span class="p">}</span>
|
||
</pre></div>
|
||
</div>
|
||
<p>where in Python you’re forced to write this:</p>
|
||
<div class="highlight-python3 notranslate"><div class="highlight"><pre><span></span><span class="k">while</span> <span class="kc">True</span><span class="p">:</span>
|
||
<span class="n">line</span> <span class="o">=</span> <span class="n">f</span><span class="o">.</span><span class="n">readline</span><span class="p">()</span>
|
||
<span class="k">if</span> <span class="ow">not</span> <span class="n">line</span><span class="p">:</span>
|
||
<span class="k">break</span>
|
||
<span class="o">...</span> <span class="c1"># do something with line</span>
|
||
</pre></div>
|
||
</div>
|
||
<p>The reason for not allowing assignment in Python expressions is a common,
|
||
hard-to-find bug in those other languages, caused by this construct:</p>
|
||
<div class="highlight-c notranslate"><div class="highlight"><pre><span></span><span class="k">if</span> <span class="p">(</span><span class="n">x</span> <span class="o">=</span> <span class="mi">0</span><span class="p">)</span> <span class="p">{</span>
|
||
<span class="c1">// error handling</span>
|
||
<span class="p">}</span>
|
||
<span class="k">else</span> <span class="p">{</span>
|
||
<span class="c1">// code that only works for nonzero x</span>
|
||
<span class="p">}</span>
|
||
</pre></div>
|
||
</div>
|
||
<p>The error is a simple typo: <code class="docutils literal notranslate"><span class="pre">x</span> <span class="pre">=</span> <span class="pre">0</span></code>, which assigns 0 to the variable <code class="docutils literal notranslate"><span class="pre">x</span></code>,
|
||
was written while the comparison <code class="docutils literal notranslate"><span class="pre">x</span> <span class="pre">==</span> <span class="pre">0</span></code> is certainly what was intended.</p>
|
||
<p>Many alternatives have been proposed. Most are hacks that save some typing but
|
||
use arbitrary or cryptic syntax or keywords, and fail the simple criterion for
|
||
language change proposals: it should intuitively suggest the proper meaning to a
|
||
human reader who has not yet been introduced to the construct.</p>
|
||
<p>An interesting phenomenon is that most experienced Python programmers recognize
|
||
the <code class="docutils literal notranslate"><span class="pre">while</span> <span class="pre">True</span></code> idiom and don’t seem to be missing the assignment in
|
||
expression construct much; it’s only newcomers who express a strong desire to
|
||
add this to the language.</p>
|
||
<p>There’s an alternative way of spelling this that seems attractive but is
|
||
generally less robust than the “while True” solution:</p>
|
||
<div class="highlight-python3 notranslate"><div class="highlight"><pre><span></span><span class="n">line</span> <span class="o">=</span> <span class="n">f</span><span class="o">.</span><span class="n">readline</span><span class="p">()</span>
|
||
<span class="k">while</span> <span class="n">line</span><span class="p">:</span>
|
||
<span class="o">...</span> <span class="c1"># do something with line...</span>
|
||
<span class="n">line</span> <span class="o">=</span> <span class="n">f</span><span class="o">.</span><span class="n">readline</span><span class="p">()</span>
|
||
</pre></div>
|
||
</div>
|
||
<p>The problem with this is that if you change your mind about exactly how you get
|
||
the next line (e.g. you want to change it into <code class="docutils literal notranslate"><span class="pre">sys.stdin.readline()</span></code>) you
|
||
have to remember to change two places in your program – the second occurrence
|
||
is hidden at the bottom of the loop.</p>
|
||
<p>The best approach is to use iterators, making it possible to loop through
|
||
objects using the <code class="docutils literal notranslate"><span class="pre">for</span></code> statement. For example, <a class="reference internal" href="../glossary.html#term-file-object"><span class="xref std std-term">file objects</span></a> support the iterator protocol, so you can write simply:</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">f</span><span class="p">:</span>
|
||
<span class="o">...</span> <span class="c1"># do something with line...</span>
|
||
</pre></div>
|
||
</div>
|
||
</div>
|
||
<div class="section" id="why-does-python-use-methods-for-some-functionality-e-g-list-index-but-functions-for-other-e-g-len-list">
|
||
<h2><a class="toc-backref" href="#id8">Why does Python use methods for some functionality (e.g. list.index()) but functions for other (e.g. len(list))?</a><a class="headerlink" href="#why-does-python-use-methods-for-some-functionality-e-g-list-index-but-functions-for-other-e-g-len-list" title="Permalink to this headline">¶</a></h2>
|
||
<p>As Guido said:</p>
|
||
<blockquote>
|
||
<div><p>(a) For some operations, prefix notation just reads better than
|
||
postfix – prefix (and infix!) operations have a long tradition in
|
||
mathematics which likes notations where the visuals help the
|
||
mathematician thinking about a problem. Compare the easy with which we
|
||
rewrite a formula like x*(a+b) into x*a + x*b to the clumsiness of
|
||
doing the same thing using a raw OO notation.</p>
|
||
<p>(b) When I read code that says len(x) I <em>know</em> that it is asking for
|
||
the length of something. This tells me two things: the result is an
|
||
integer, and the argument is some kind of container. To the contrary,
|
||
when I read x.len(), I have to already know that x is some kind of
|
||
container implementing an interface or inheriting from a class that
|
||
has a standard len(). Witness the confusion we occasionally have when
|
||
a class that is not implementing a mapping has a get() or keys()
|
||
method, or something that isn’t a file has a write() method.</p>
|
||
<p class="attribution">—<a class="reference external" href="https://mail.python.org/pipermail/python-3000/2006-November/004643.html">https://mail.python.org/pipermail/python-3000/2006-November/004643.html</a></p>
|
||
</div></blockquote>
|
||
</div>
|
||
<div class="section" id="why-is-join-a-string-method-instead-of-a-list-or-tuple-method">
|
||
<h2><a class="toc-backref" href="#id9">Why is join() a string method instead of a list or tuple method?</a><a class="headerlink" href="#why-is-join-a-string-method-instead-of-a-list-or-tuple-method" title="Permalink to this headline">¶</a></h2>
|
||
<p>Strings became much more like other standard types starting in Python 1.6, when
|
||
methods were added which give the same functionality that has always been
|
||
available using the functions of the string module. Most of these new methods
|
||
have been widely accepted, but the one which appears to make some programmers
|
||
feel uncomfortable is:</p>
|
||
<div class="highlight-python3 notranslate"><div class="highlight"><pre><span></span><span class="s2">", "</span><span class="o">.</span><span class="n">join</span><span class="p">([</span><span class="s1">'1'</span><span class="p">,</span> <span class="s1">'2'</span><span class="p">,</span> <span class="s1">'4'</span><span class="p">,</span> <span class="s1">'8'</span><span class="p">,</span> <span class="s1">'16'</span><span class="p">])</span>
|
||
</pre></div>
|
||
</div>
|
||
<p>which gives the result:</p>
|
||
<div class="highlight-python3 notranslate"><div class="highlight"><pre><span></span><span class="s2">"1, 2, 4, 8, 16"</span>
|
||
</pre></div>
|
||
</div>
|
||
<p>There are two common arguments against this usage.</p>
|
||
<p>The first runs along the lines of: “It looks really ugly using a method of a
|
||
string literal (string constant)”, to which the answer is that it might, but a
|
||
string literal is just a fixed value. If the methods are to be allowed on names
|
||
bound to strings there is no logical reason to make them unavailable on
|
||
literals.</p>
|
||
<p>The second objection is typically cast as: “I am really telling a sequence to
|
||
join its members together with a string constant”. Sadly, you aren’t. For some
|
||
reason there seems to be much less difficulty with having <a class="reference internal" href="../library/stdtypes.html#str.split" title="str.split"><code class="xref py py-meth docutils literal notranslate"><span class="pre">split()</span></code></a> as
|
||
a string method, since in that case it is easy to see that</p>
|
||
<div class="highlight-python3 notranslate"><div class="highlight"><pre><span></span><span class="s2">"1, 2, 4, 8, 16"</span><span class="o">.</span><span class="n">split</span><span class="p">(</span><span class="s2">", "</span><span class="p">)</span>
|
||
</pre></div>
|
||
</div>
|
||
<p>is an instruction to a string literal to return the substrings delimited by the
|
||
given separator (or, by default, arbitrary runs of white space).</p>
|
||
<p><a class="reference internal" href="../library/stdtypes.html#str.join" title="str.join"><code class="xref py py-meth docutils literal notranslate"><span class="pre">join()</span></code></a> is a string method because in using it you are telling the
|
||
separator string to iterate over a sequence of strings and insert itself between
|
||
adjacent elements. This method can be used with any argument which obeys the
|
||
rules for sequence objects, including any new classes you might define yourself.
|
||
Similar methods exist for bytes and bytearray objects.</p>
|
||
</div>
|
||
<div class="section" id="how-fast-are-exceptions">
|
||
<h2><a class="toc-backref" href="#id10">How fast are exceptions?</a><a class="headerlink" href="#how-fast-are-exceptions" title="Permalink to this headline">¶</a></h2>
|
||
<p>A try/except block is extremely efficient if no exceptions are raised. Actually
|
||
catching an exception is expensive. In versions of Python prior to 2.0 it was
|
||
common to use this idiom:</p>
|
||
<div class="highlight-python3 notranslate"><div class="highlight"><pre><span></span><span class="k">try</span><span class="p">:</span>
|
||
<span class="n">value</span> <span class="o">=</span> <span class="n">mydict</span><span class="p">[</span><span class="n">key</span><span class="p">]</span>
|
||
<span class="k">except</span> <span class="ne">KeyError</span><span class="p">:</span>
|
||
<span class="n">mydict</span><span class="p">[</span><span class="n">key</span><span class="p">]</span> <span class="o">=</span> <span class="n">getvalue</span><span class="p">(</span><span class="n">key</span><span class="p">)</span>
|
||
<span class="n">value</span> <span class="o">=</span> <span class="n">mydict</span><span class="p">[</span><span class="n">key</span><span class="p">]</span>
|
||
</pre></div>
|
||
</div>
|
||
<p>This only made sense when you expected the dict to have the key almost all the
|
||
time. If that wasn’t the case, you coded it like this:</p>
|
||
<div class="highlight-python3 notranslate"><div class="highlight"><pre><span></span><span class="k">if</span> <span class="n">key</span> <span class="ow">in</span> <span class="n">mydict</span><span class="p">:</span>
|
||
<span class="n">value</span> <span class="o">=</span> <span class="n">mydict</span><span class="p">[</span><span class="n">key</span><span class="p">]</span>
|
||
<span class="k">else</span><span class="p">:</span>
|
||
<span class="n">value</span> <span class="o">=</span> <span class="n">mydict</span><span class="p">[</span><span class="n">key</span><span class="p">]</span> <span class="o">=</span> <span class="n">getvalue</span><span class="p">(</span><span class="n">key</span><span class="p">)</span>
|
||
</pre></div>
|
||
</div>
|
||
<p>For this specific case, you could also use <code class="docutils literal notranslate"><span class="pre">value</span> <span class="pre">=</span> <span class="pre">dict.setdefault(key,</span>
|
||
<span class="pre">getvalue(key))</span></code>, but only if the <code class="docutils literal notranslate"><span class="pre">getvalue()</span></code> call is cheap enough because it
|
||
is evaluated in all cases.</p>
|
||
</div>
|
||
<div class="section" id="why-isn-t-there-a-switch-or-case-statement-in-python">
|
||
<h2><a class="toc-backref" href="#id11">Why isn’t there a switch or case statement in Python?</a><a class="headerlink" href="#why-isn-t-there-a-switch-or-case-statement-in-python" title="Permalink to this headline">¶</a></h2>
|
||
<p>You can do this easily enough with a sequence of <code class="docutils literal notranslate"><span class="pre">if...</span> <span class="pre">elif...</span> <span class="pre">elif...</span> <span class="pre">else</span></code>.
|
||
There have been some proposals for switch statement syntax, but there is no
|
||
consensus (yet) on whether and how to do range tests. See <span class="target" id="index-0"></span><a class="pep reference external" href="https://www.python.org/dev/peps/pep-0275"><strong>PEP 275</strong></a> for
|
||
complete details and the current status.</p>
|
||
<p>For cases where you need to choose from a very large number of possibilities,
|
||
you can create a dictionary mapping case values to functions to call. For
|
||
example:</p>
|
||
<div class="highlight-python3 notranslate"><div class="highlight"><pre><span></span><span class="k">def</span> <span class="nf">function_1</span><span class="p">(</span><span class="o">...</span><span class="p">):</span>
|
||
<span class="o">...</span>
|
||
|
||
<span class="n">functions</span> <span class="o">=</span> <span class="p">{</span><span class="s1">'a'</span><span class="p">:</span> <span class="n">function_1</span><span class="p">,</span>
|
||
<span class="s1">'b'</span><span class="p">:</span> <span class="n">function_2</span><span class="p">,</span>
|
||
<span class="s1">'c'</span><span class="p">:</span> <span class="bp">self</span><span class="o">.</span><span class="n">method_1</span><span class="p">,</span> <span class="o">...</span><span class="p">}</span>
|
||
|
||
<span class="n">func</span> <span class="o">=</span> <span class="n">functions</span><span class="p">[</span><span class="n">value</span><span class="p">]</span>
|
||
<span class="n">func</span><span class="p">()</span>
|
||
</pre></div>
|
||
</div>
|
||
<p>For calling methods on objects, you can simplify yet further by using the
|
||
<a class="reference internal" href="../library/functions.html#getattr" title="getattr"><code class="xref py py-func docutils literal notranslate"><span class="pre">getattr()</span></code></a> built-in to retrieve methods with a particular name:</p>
|
||
<div class="highlight-python3 notranslate"><div class="highlight"><pre><span></span><span class="k">def</span> <span class="nf">visit_a</span><span class="p">(</span><span class="bp">self</span><span class="p">,</span> <span class="o">...</span><span class="p">):</span>
|
||
<span class="o">...</span>
|
||
<span class="o">...</span>
|
||
|
||
<span class="k">def</span> <span class="nf">dispatch</span><span class="p">(</span><span class="bp">self</span><span class="p">,</span> <span class="n">value</span><span class="p">):</span>
|
||
<span class="n">method_name</span> <span class="o">=</span> <span class="s1">'visit_'</span> <span class="o">+</span> <span class="nb">str</span><span class="p">(</span><span class="n">value</span><span class="p">)</span>
|
||
<span class="n">method</span> <span class="o">=</span> <span class="nb">getattr</span><span class="p">(</span><span class="bp">self</span><span class="p">,</span> <span class="n">method_name</span><span class="p">)</span>
|
||
<span class="n">method</span><span class="p">()</span>
|
||
</pre></div>
|
||
</div>
|
||
<p>It’s suggested that you use a prefix for the method names, such as <code class="docutils literal notranslate"><span class="pre">visit_</span></code> in
|
||
this example. Without such a prefix, if values are coming from an untrusted
|
||
source, an attacker would be able to call any method on your object.</p>
|
||
</div>
|
||
<div class="section" id="can-t-you-emulate-threads-in-the-interpreter-instead-of-relying-on-an-os-specific-thread-implementation">
|
||
<h2><a class="toc-backref" href="#id12">Can’t you emulate threads in the interpreter instead of relying on an OS-specific thread implementation?</a><a class="headerlink" href="#can-t-you-emulate-threads-in-the-interpreter-instead-of-relying-on-an-os-specific-thread-implementation" title="Permalink to this headline">¶</a></h2>
|
||
<p>Answer 1: Unfortunately, the interpreter pushes at least one C stack frame for
|
||
each Python stack frame. Also, extensions can call back into Python at almost
|
||
random moments. Therefore, a complete threads implementation requires thread
|
||
support for C.</p>
|
||
<p>Answer 2: Fortunately, there is <a class="reference external" href="https://github.com/stackless-dev/stackless/wiki">Stackless Python</a>,
|
||
which has a completely redesigned interpreter loop that avoids the C stack.</p>
|
||
</div>
|
||
<div class="section" id="why-can-t-lambda-expressions-contain-statements">
|
||
<h2><a class="toc-backref" href="#id13">Why can’t lambda expressions contain statements?</a><a class="headerlink" href="#why-can-t-lambda-expressions-contain-statements" title="Permalink to this headline">¶</a></h2>
|
||
<p>Python lambda expressions cannot contain statements because Python’s syntactic
|
||
framework can’t handle statements nested inside expressions. However, in
|
||
Python, this is not a serious problem. Unlike lambda forms in other languages,
|
||
where they add functionality, Python lambdas are only a shorthand notation if
|
||
you’re too lazy to define a function.</p>
|
||
<p>Functions are already first class objects in Python, and can be declared in a
|
||
local scope. Therefore the only advantage of using a lambda instead of a
|
||
locally-defined function is that you don’t need to invent a name for the
|
||
function – but that’s just a local variable to which the function object (which
|
||
is exactly the same type of object that a lambda expression yields) is assigned!</p>
|
||
</div>
|
||
<div class="section" id="can-python-be-compiled-to-machine-code-c-or-some-other-language">
|
||
<h2><a class="toc-backref" href="#id14">Can Python be compiled to machine code, C or some other language?</a><a class="headerlink" href="#can-python-be-compiled-to-machine-code-c-or-some-other-language" title="Permalink to this headline">¶</a></h2>
|
||
<p><a class="reference external" href="http://cython.org/">Cython</a> compiles a modified version of Python with
|
||
optional annotations into C extensions. <a class="reference external" href="http://www.nuitka.net/">Nuitka</a> is
|
||
an up-and-coming compiler of Python into C++ code, aiming to support the full
|
||
Python language. For compiling to Java you can consider
|
||
<a class="reference external" href="https://voc.readthedocs.io">VOC</a>.</p>
|
||
</div>
|
||
<div class="section" id="how-does-python-manage-memory">
|
||
<h2><a class="toc-backref" href="#id15">How does Python manage memory?</a><a class="headerlink" href="#how-does-python-manage-memory" title="Permalink to this headline">¶</a></h2>
|
||
<p>The details of Python memory management depend on the implementation. The
|
||
standard implementation of Python, <a class="reference internal" href="../glossary.html#term-cpython"><span class="xref std std-term">CPython</span></a>, uses reference counting to
|
||
detect inaccessible objects, and another mechanism to collect reference cycles,
|
||
periodically executing a cycle detection algorithm which looks for inaccessible
|
||
cycles and deletes the objects involved. The <a class="reference internal" href="../library/gc.html#module-gc" title="gc: Interface to the cycle-detecting garbage collector."><code class="xref py py-mod docutils literal notranslate"><span class="pre">gc</span></code></a> module provides functions
|
||
to perform a garbage collection, obtain debugging statistics, and tune the
|
||
collector’s parameters.</p>
|
||
<p>Other implementations (such as <a class="reference external" href="http://www.jython.org">Jython</a> or
|
||
<a class="reference external" href="http://www.pypy.org">PyPy</a>), however, can rely on a different mechanism
|
||
such as a full-blown garbage collector. This difference can cause some
|
||
subtle porting problems if your Python code depends on the behavior of the
|
||
reference counting implementation.</p>
|
||
<p>In some Python implementations, the following code (which is fine in CPython)
|
||
will probably run out of file descriptors:</p>
|
||
<div class="highlight-python3 notranslate"><div class="highlight"><pre><span></span><span class="k">for</span> <span class="n">file</span> <span class="ow">in</span> <span class="n">very_long_list_of_files</span><span class="p">:</span>
|
||
<span class="n">f</span> <span class="o">=</span> <span class="nb">open</span><span class="p">(</span><span class="n">file</span><span class="p">)</span>
|
||
<span class="n">c</span> <span class="o">=</span> <span class="n">f</span><span class="o">.</span><span class="n">read</span><span class="p">(</span><span class="mi">1</span><span class="p">)</span>
|
||
</pre></div>
|
||
</div>
|
||
<p>Indeed, using CPython’s reference counting and destructor scheme, each new
|
||
assignment to <em>f</em> closes the previous file. With a traditional GC, however,
|
||
those file objects will only get collected (and closed) at varying and possibly
|
||
long intervals.</p>
|
||
<p>If you want to write code that will work with any Python implementation,
|
||
you should explicitly close the file or use the <a class="reference internal" href="../reference/compound_stmts.html#with"><code class="xref std std-keyword docutils literal notranslate"><span class="pre">with</span></code></a> statement;
|
||
this will work regardless of memory management scheme:</p>
|
||
<div class="highlight-python3 notranslate"><div class="highlight"><pre><span></span><span class="k">for</span> <span class="n">file</span> <span class="ow">in</span> <span class="n">very_long_list_of_files</span><span class="p">:</span>
|
||
<span class="k">with</span> <span class="nb">open</span><span class="p">(</span><span class="n">file</span><span class="p">)</span> <span class="k">as</span> <span class="n">f</span><span class="p">:</span>
|
||
<span class="n">c</span> <span class="o">=</span> <span class="n">f</span><span class="o">.</span><span class="n">read</span><span class="p">(</span><span class="mi">1</span><span class="p">)</span>
|
||
</pre></div>
|
||
</div>
|
||
</div>
|
||
<div class="section" id="why-doesn-t-cpython-use-a-more-traditional-garbage-collection-scheme">
|
||
<h2><a class="toc-backref" href="#id16">Why doesn’t CPython use a more traditional garbage collection scheme?</a><a class="headerlink" href="#why-doesn-t-cpython-use-a-more-traditional-garbage-collection-scheme" title="Permalink to this headline">¶</a></h2>
|
||
<p>For one thing, this is not a C standard feature and hence it’s not portable.
|
||
(Yes, we know about the Boehm GC library. It has bits of assembler code for
|
||
<em>most</em> common platforms, not for all of them, and although it is mostly
|
||
transparent, it isn’t completely transparent; patches are required to get
|
||
Python to work with it.)</p>
|
||
<p>Traditional GC also becomes a problem when Python is embedded into other
|
||
applications. While in a standalone Python it’s fine to replace the standard
|
||
malloc() and free() with versions provided by the GC library, an application
|
||
embedding Python may want to have its <em>own</em> substitute for malloc() and free(),
|
||
and may not want Python’s. Right now, CPython works with anything that
|
||
implements malloc() and free() properly.</p>
|
||
</div>
|
||
<div class="section" id="why-isn-t-all-memory-freed-when-cpython-exits">
|
||
<h2><a class="toc-backref" href="#id17">Why isn’t all memory freed when CPython exits?</a><a class="headerlink" href="#why-isn-t-all-memory-freed-when-cpython-exits" title="Permalink to this headline">¶</a></h2>
|
||
<p>Objects referenced from the global namespaces of Python modules are not always
|
||
deallocated when Python exits. This may happen if there are circular
|
||
references. There are also certain bits of memory that are allocated by the C
|
||
library that are impossible to free (e.g. a tool like Purify will complain about
|
||
these). Python is, however, aggressive about cleaning up memory on exit and
|
||
does try to destroy every single object.</p>
|
||
<p>If you want to force Python to delete certain things on deallocation use the
|
||
<a class="reference internal" href="../library/atexit.html#module-atexit" title="atexit: Register and execute cleanup functions."><code class="xref py py-mod docutils literal notranslate"><span class="pre">atexit</span></code></a> module to run a function that will force those deletions.</p>
|
||
</div>
|
||
<div class="section" id="why-are-there-separate-tuple-and-list-data-types">
|
||
<h2><a class="toc-backref" href="#id18">Why are there separate tuple and list data types?</a><a class="headerlink" href="#why-are-there-separate-tuple-and-list-data-types" title="Permalink to this headline">¶</a></h2>
|
||
<p>Lists and tuples, while similar in many respects, are generally used in
|
||
fundamentally different ways. Tuples can be thought of as being similar to
|
||
Pascal records or C structs; they’re small collections of related data which may
|
||
be of different types which are operated on as a group. For example, a
|
||
Cartesian coordinate is appropriately represented as a tuple of two or three
|
||
numbers.</p>
|
||
<p>Lists, on the other hand, are more like arrays in other languages. They tend to
|
||
hold a varying number of objects all of which have the same type and which are
|
||
operated on one-by-one. For example, <code class="docutils literal notranslate"><span class="pre">os.listdir('.')</span></code> returns a list of
|
||
strings representing the files in the current directory. Functions which
|
||
operate on this output would generally not break if you added another file or
|
||
two to the directory.</p>
|
||
<p>Tuples are immutable, meaning that once a tuple has been created, you can’t
|
||
replace any of its elements with a new value. Lists are mutable, meaning that
|
||
you can always change a list’s elements. Only immutable elements can be used as
|
||
dictionary keys, and hence only tuples and not lists can be used as keys.</p>
|
||
</div>
|
||
<div class="section" id="how-are-lists-implemented-in-cpython">
|
||
<h2><a class="toc-backref" href="#id19">How are lists implemented in CPython?</a><a class="headerlink" href="#how-are-lists-implemented-in-cpython" title="Permalink to this headline">¶</a></h2>
|
||
<p>CPython’s lists are really variable-length arrays, not Lisp-style linked lists.
|
||
The implementation uses a contiguous array of references to other objects, and
|
||
keeps a pointer to this array and the array’s length in a list head structure.</p>
|
||
<p>This makes indexing a list <code class="docutils literal notranslate"><span class="pre">a[i]</span></code> an operation whose cost is independent of
|
||
the size of the list or the value of the index.</p>
|
||
<p>When items are appended or inserted, the array of references is resized. Some
|
||
cleverness is applied to improve the performance of appending items repeatedly;
|
||
when the array must be grown, some extra space is allocated so the next few
|
||
times don’t require an actual resize.</p>
|
||
</div>
|
||
<div class="section" id="how-are-dictionaries-implemented-in-cpython">
|
||
<h2><a class="toc-backref" href="#id20">How are dictionaries implemented in CPython?</a><a class="headerlink" href="#how-are-dictionaries-implemented-in-cpython" title="Permalink to this headline">¶</a></h2>
|
||
<p>CPython’s dictionaries are implemented as resizable hash tables. Compared to
|
||
B-trees, this gives better performance for lookup (the most common operation by
|
||
far) under most circumstances, and the implementation is simpler.</p>
|
||
<p>Dictionaries work by computing a hash code for each key stored in the dictionary
|
||
using the <a class="reference internal" href="../library/functions.html#hash" title="hash"><code class="xref py py-func docutils literal notranslate"><span class="pre">hash()</span></code></a> built-in function. The hash code varies widely depending
|
||
on the key and a per-process seed; for example, “Python” could hash to
|
||
-539294296 while “python”, a string that differs by a single bit, could hash
|
||
to 1142331976. The hash code is then used to calculate a location in an
|
||
internal array where the value will be stored. Assuming that you’re storing
|
||
keys that all have different hash values, this means that dictionaries take
|
||
constant time – O(1), in Big-O notation – to retrieve a key.</p>
|
||
</div>
|
||
<div class="section" id="why-must-dictionary-keys-be-immutable">
|
||
<h2><a class="toc-backref" href="#id21">Why must dictionary keys be immutable?</a><a class="headerlink" href="#why-must-dictionary-keys-be-immutable" title="Permalink to this headline">¶</a></h2>
|
||
<p>The hash table implementation of dictionaries uses a hash value calculated from
|
||
the key value to find the key. If the key were a mutable object, its value
|
||
could change, and thus its hash could also change. But since whoever changes
|
||
the key object can’t tell that it was being used as a dictionary key, it can’t
|
||
move the entry around in the dictionary. Then, when you try to look up the same
|
||
object in the dictionary it won’t be found because its hash value is different.
|
||
If you tried to look up the old value it wouldn’t be found either, because the
|
||
value of the object found in that hash bin would be different.</p>
|
||
<p>If you want a dictionary indexed with a list, simply convert the list to a tuple
|
||
first; the function <code class="docutils literal notranslate"><span class="pre">tuple(L)</span></code> creates a tuple with the same entries as the
|
||
list <code class="docutils literal notranslate"><span class="pre">L</span></code>. Tuples are immutable and can therefore be used as dictionary keys.</p>
|
||
<p>Some unacceptable solutions that have been proposed:</p>
|
||
<ul>
|
||
<li><p>Hash lists by their address (object ID). This doesn’t work because if you
|
||
construct a new list with the same value it won’t be found; e.g.:</p>
|
||
<div class="highlight-python3 notranslate"><div class="highlight"><pre><span></span><span class="n">mydict</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="s1">'12'</span><span class="p">}</span>
|
||
<span class="nb">print</span><span class="p">(</span><span class="n">mydict</span><span class="p">[[</span><span class="mi">1</span><span class="p">,</span> <span class="mi">2</span><span class="p">]])</span>
|
||
</pre></div>
|
||
</div>
|
||
<p>would raise a <a class="reference internal" href="../library/exceptions.html#KeyError" title="KeyError"><code class="xref py py-exc docutils literal notranslate"><span class="pre">KeyError</span></code></a> exception because the id of the <code class="docutils literal notranslate"><span class="pre">[1,</span> <span class="pre">2]</span></code> used in the
|
||
second line differs from that in the first line. In other words, dictionary
|
||
keys should be compared using <code class="docutils literal notranslate"><span class="pre">==</span></code>, not using <a class="reference internal" href="../reference/expressions.html#is"><code class="xref std std-keyword docutils literal notranslate"><span class="pre">is</span></code></a>.</p>
|
||
</li>
|
||
<li><p>Make a copy when using a list as a key. This doesn’t work because the list,
|
||
being a mutable object, could contain a reference to itself, and then the
|
||
copying code would run into an infinite loop.</p></li>
|
||
<li><p>Allow lists as keys but tell the user not to modify them. This would allow a
|
||
class of hard-to-track bugs in programs when you forgot or modified a list by
|
||
accident. It also invalidates an important invariant of dictionaries: every
|
||
value in <code class="docutils literal notranslate"><span class="pre">d.keys()</span></code> is usable as a key of the dictionary.</p></li>
|
||
<li><p>Mark lists as read-only once they are used as a dictionary key. The problem
|
||
is that it’s not just the top-level object that could change its value; you
|
||
could use a tuple containing a list as a key. Entering anything as a key into
|
||
a dictionary would require marking all objects reachable from there as
|
||
read-only – and again, self-referential objects could cause an infinite loop.</p></li>
|
||
</ul>
|
||
<p>There is a trick to get around this if you need to, but use it at your own risk:
|
||
You can wrap a mutable structure inside a class instance which has both a
|
||
<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> and a <a class="reference internal" href="../reference/datamodel.html#object.__hash__" title="object.__hash__"><code class="xref py py-meth docutils literal notranslate"><span class="pre">__hash__()</span></code></a> method. You must then make sure that the
|
||
hash value for all such wrapper objects that reside in a dictionary (or other
|
||
hash based structure), remain fixed while the object is in the dictionary (or
|
||
other structure).</p>
|
||
<div class="highlight-python3 notranslate"><div class="highlight"><pre><span></span><span class="k">class</span> <span class="nc">ListWrapper</span><span class="p">:</span>
|
||
<span class="k">def</span> <span class="nf">__init__</span><span class="p">(</span><span class="bp">self</span><span class="p">,</span> <span class="n">the_list</span><span class="p">):</span>
|
||
<span class="bp">self</span><span class="o">.</span><span class="n">the_list</span> <span class="o">=</span> <span class="n">the_list</span>
|
||
|
||
<span class="k">def</span> <span class="nf">__eq__</span><span class="p">(</span><span class="bp">self</span><span class="p">,</span> <span class="n">other</span><span class="p">):</span>
|
||
<span class="k">return</span> <span class="bp">self</span><span class="o">.</span><span class="n">the_list</span> <span class="o">==</span> <span class="n">other</span><span class="o">.</span><span class="n">the_list</span>
|
||
|
||
<span class="k">def</span> <span class="nf">__hash__</span><span class="p">(</span><span class="bp">self</span><span class="p">):</span>
|
||
<span class="n">l</span> <span class="o">=</span> <span class="bp">self</span><span class="o">.</span><span class="n">the_list</span>
|
||
<span class="n">result</span> <span class="o">=</span> <span class="mi">98767</span> <span class="o">-</span> <span class="nb">len</span><span class="p">(</span><span class="n">l</span><span class="p">)</span><span class="o">*</span><span class="mi">555</span>
|
||
<span class="k">for</span> <span class="n">i</span><span class="p">,</span> <span class="n">el</span> <span class="ow">in</span> <span class="nb">enumerate</span><span class="p">(</span><span class="n">l</span><span class="p">):</span>
|
||
<span class="k">try</span><span class="p">:</span>
|
||
<span class="n">result</span> <span class="o">=</span> <span class="n">result</span> <span class="o">+</span> <span class="p">(</span><span class="nb">hash</span><span class="p">(</span><span class="n">el</span><span class="p">)</span> <span class="o">%</span> <span class="mi">9999999</span><span class="p">)</span> <span class="o">*</span> <span class="mi">1001</span> <span class="o">+</span> <span class="n">i</span>
|
||
<span class="k">except</span> <span class="ne">Exception</span><span class="p">:</span>
|
||
<span class="n">result</span> <span class="o">=</span> <span class="p">(</span><span class="n">result</span> <span class="o">%</span> <span class="mi">7777777</span><span class="p">)</span> <span class="o">+</span> <span class="n">i</span> <span class="o">*</span> <span class="mi">333</span>
|
||
<span class="k">return</span> <span class="n">result</span>
|
||
</pre></div>
|
||
</div>
|
||
<p>Note that the hash computation is complicated by the possibility that some
|
||
members of the list may be unhashable and also by the possibility of arithmetic
|
||
overflow.</p>
|
||
<p>Furthermore it must always be the case that if <code class="docutils literal notranslate"><span class="pre">o1</span> <span class="pre">==</span> <span class="pre">o2</span></code> (ie <code class="docutils literal notranslate"><span class="pre">o1.__eq__(o2)</span>
|
||
<span class="pre">is</span> <span class="pre">True</span></code>) then <code class="docutils literal notranslate"><span class="pre">hash(o1)</span> <span class="pre">==</span> <span class="pre">hash(o2)</span></code> (ie, <code class="docutils literal notranslate"><span class="pre">o1.__hash__()</span> <span class="pre">==</span> <span class="pre">o2.__hash__()</span></code>),
|
||
regardless of whether the object is in a dictionary or not. If you fail to meet
|
||
these restrictions dictionaries and other hash based structures will misbehave.</p>
|
||
<p>In the case of ListWrapper, whenever the wrapper object is in a dictionary the
|
||
wrapped list must not change to avoid anomalies. Don’t do this unless you are
|
||
prepared to think hard about the requirements and the consequences of not
|
||
meeting them correctly. Consider yourself warned.</p>
|
||
</div>
|
||
<div class="section" id="why-doesn-t-list-sort-return-the-sorted-list">
|
||
<h2><a class="toc-backref" href="#id22">Why doesn’t list.sort() return the sorted list?</a><a class="headerlink" href="#why-doesn-t-list-sort-return-the-sorted-list" title="Permalink to this headline">¶</a></h2>
|
||
<p>In situations where performance matters, making a copy of the list just to sort
|
||
it would be wasteful. Therefore, <a class="reference internal" href="../library/stdtypes.html#list.sort" title="list.sort"><code class="xref py py-meth docutils literal notranslate"><span class="pre">list.sort()</span></code></a> sorts the list in place. In
|
||
order to remind you of that fact, it does not return the sorted list. This way,
|
||
you won’t be fooled into accidentally overwriting a list when you need a sorted
|
||
copy but also need to keep the unsorted version around.</p>
|
||
<p>If you want to return a new list, use the built-in <a class="reference internal" href="../library/functions.html#sorted" title="sorted"><code class="xref py py-func docutils literal notranslate"><span class="pre">sorted()</span></code></a> function
|
||
instead. This function creates a new list from a provided iterable, sorts
|
||
it and returns it. For example, here’s how to iterate over the keys of a
|
||
dictionary in sorted order:</p>
|
||
<div class="highlight-python3 notranslate"><div class="highlight"><pre><span></span><span class="k">for</span> <span class="n">key</span> <span class="ow">in</span> <span class="nb">sorted</span><span class="p">(</span><span class="n">mydict</span><span class="p">):</span>
|
||
<span class="o">...</span> <span class="c1"># do whatever with mydict[key]...</span>
|
||
</pre></div>
|
||
</div>
|
||
</div>
|
||
<div class="section" id="how-do-you-specify-and-enforce-an-interface-spec-in-python">
|
||
<h2><a class="toc-backref" href="#id23">How do you specify and enforce an interface spec in Python?</a><a class="headerlink" href="#how-do-you-specify-and-enforce-an-interface-spec-in-python" title="Permalink to this headline">¶</a></h2>
|
||
<p>An interface specification for a module as provided by languages such as C++ and
|
||
Java describes the prototypes for the methods and functions of the module. Many
|
||
feel that compile-time enforcement of interface specifications helps in the
|
||
construction of large programs.</p>
|
||
<p>Python 2.6 adds an <a class="reference internal" href="../library/abc.html#module-abc" title="abc: Abstract base classes according to PEP 3119."><code class="xref py py-mod docutils literal notranslate"><span class="pre">abc</span></code></a> module that lets you define Abstract Base Classes
|
||
(ABCs). You can then use <a class="reference internal" href="../library/functions.html#isinstance" title="isinstance"><code class="xref py py-func docutils literal notranslate"><span class="pre">isinstance()</span></code></a> and <a class="reference internal" href="../library/functions.html#issubclass" title="issubclass"><code class="xref py py-func docutils literal notranslate"><span class="pre">issubclass()</span></code></a> to check
|
||
whether an instance or a class implements a particular ABC. The
|
||
<a class="reference internal" href="../library/collections.abc.html#module-collections.abc" title="collections.abc: Abstract base classes for containers"><code class="xref py py-mod docutils literal notranslate"><span class="pre">collections.abc</span></code></a> module defines a set of useful ABCs such as
|
||
<a class="reference internal" href="../library/collections.abc.html#collections.abc.Iterable" title="collections.abc.Iterable"><code class="xref py py-class docutils literal notranslate"><span class="pre">Iterable</span></code></a>, <a class="reference internal" href="../library/collections.abc.html#collections.abc.Container" title="collections.abc.Container"><code class="xref py py-class docutils literal notranslate"><span class="pre">Container</span></code></a>, and
|
||
<a class="reference internal" href="../library/collections.abc.html#collections.abc.MutableMapping" title="collections.abc.MutableMapping"><code class="xref py py-class docutils literal notranslate"><span class="pre">MutableMapping</span></code></a>.</p>
|
||
<p>For Python, many of the advantages of interface specifications can be obtained
|
||
by an appropriate test discipline for components. There is also a tool,
|
||
PyChecker, which can be used to find problems due to subclassing.</p>
|
||
<p>A good test suite for a module can both provide a regression test and serve as a
|
||
module interface specification and a set of examples. Many Python modules can
|
||
be run as a script to provide a simple “self test.” Even modules which use
|
||
complex external interfaces can often be tested in isolation using trivial
|
||
“stub” emulations of the external interface. 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> and
|
||
<a class="reference internal" href="../library/unittest.html#module-unittest" title="unittest: Unit testing framework for Python."><code class="xref py py-mod docutils literal notranslate"><span class="pre">unittest</span></code></a> modules or third-party test frameworks can be used to construct
|
||
exhaustive test suites that exercise every line of code in a module.</p>
|
||
<p>An appropriate testing discipline can help build large complex applications in
|
||
Python as well as having interface specifications would. In fact, it can be
|
||
better because an interface specification cannot test certain properties of a
|
||
program. For example, the <code class="xref py py-meth docutils literal notranslate"><span class="pre">append()</span></code> method is expected to add new elements
|
||
to the end of some internal list; an interface specification cannot test that
|
||
your <code class="xref py py-meth docutils literal notranslate"><span class="pre">append()</span></code> implementation will actually do this correctly, but it’s
|
||
trivial to check this property in a test suite.</p>
|
||
<p>Writing test suites is very helpful, and you might want to design your code with
|
||
an eye to making it easily tested. One increasingly popular technique,
|
||
test-directed development, calls for writing parts of the test suite first,
|
||
before you write any of the actual code. Of course Python allows you to be
|
||
sloppy and not write test cases at all.</p>
|
||
</div>
|
||
<div class="section" id="why-is-there-no-goto">
|
||
<h2><a class="toc-backref" href="#id24">Why is there no goto?</a><a class="headerlink" href="#why-is-there-no-goto" title="Permalink to this headline">¶</a></h2>
|
||
<p>You can use exceptions to provide a “structured goto” that even works across
|
||
function calls. Many feel that exceptions can conveniently emulate all
|
||
reasonable uses of the “go” or “goto” constructs of C, Fortran, and other
|
||
languages. For example:</p>
|
||
<div class="highlight-python3 notranslate"><div class="highlight"><pre><span></span><span class="k">class</span> <span class="nc">label</span><span class="p">(</span><span class="ne">Exception</span><span class="p">):</span> <span class="k">pass</span> <span class="c1"># declare a label</span>
|
||
|
||
<span class="k">try</span><span class="p">:</span>
|
||
<span class="o">...</span>
|
||
<span class="k">if</span> <span class="n">condition</span><span class="p">:</span> <span class="k">raise</span> <span class="n">label</span><span class="p">()</span> <span class="c1"># goto label</span>
|
||
<span class="o">...</span>
|
||
<span class="k">except</span> <span class="n">label</span><span class="p">:</span> <span class="c1"># where to goto</span>
|
||
<span class="k">pass</span>
|
||
<span class="o">...</span>
|
||
</pre></div>
|
||
</div>
|
||
<p>This doesn’t allow you to jump into the middle of a loop, but that’s usually
|
||
considered an abuse of goto anyway. Use sparingly.</p>
|
||
</div>
|
||
<div class="section" id="why-can-t-raw-strings-r-strings-end-with-a-backslash">
|
||
<h2><a class="toc-backref" href="#id25">Why can’t raw strings (r-strings) end with a backslash?</a><a class="headerlink" href="#why-can-t-raw-strings-r-strings-end-with-a-backslash" title="Permalink to this headline">¶</a></h2>
|
||
<p>More precisely, they can’t end with an odd number of backslashes: the unpaired
|
||
backslash at the end escapes the closing quote character, leaving an
|
||
unterminated string.</p>
|
||
<p>Raw strings were designed to ease creating input for processors (chiefly regular
|
||
expression engines) that want to do their own backslash escape processing. Such
|
||
processors consider an unmatched trailing backslash to be an error anyway, so
|
||
raw strings disallow that. In return, they allow you to pass on the string
|
||
quote character by escaping it with a backslash. These rules work well when
|
||
r-strings are used for their intended purpose.</p>
|
||
<p>If you’re trying to build Windows pathnames, note that all Windows system calls
|
||
accept forward slashes too:</p>
|
||
<div class="highlight-python3 notranslate"><div class="highlight"><pre><span></span><span class="n">f</span> <span class="o">=</span> <span class="nb">open</span><span class="p">(</span><span class="s2">"/mydir/file.txt"</span><span class="p">)</span> <span class="c1"># works fine!</span>
|
||
</pre></div>
|
||
</div>
|
||
<p>If you’re trying to build a pathname for a DOS command, try e.g. one of</p>
|
||
<div class="highlight-python3 notranslate"><div class="highlight"><pre><span></span><span class="nb">dir</span> <span class="o">=</span> <span class="sa">r</span><span class="s2">"\this\is\my\dos\dir"</span> <span class="s2">"</span><span class="se">\\</span><span class="s2">"</span>
|
||
<span class="nb">dir</span> <span class="o">=</span> <span class="sa">r</span><span class="s2">"\this\is\my\dos\dir\ "</span><span class="p">[:</span><span class="o">-</span><span class="mi">1</span><span class="p">]</span>
|
||
<span class="nb">dir</span> <span class="o">=</span> <span class="s2">"</span><span class="se">\\</span><span class="s2">this</span><span class="se">\\</span><span class="s2">is</span><span class="se">\\</span><span class="s2">my</span><span class="se">\\</span><span class="s2">dos</span><span class="se">\\</span><span class="s2">dir</span><span class="se">\\</span><span class="s2">"</span>
|
||
</pre></div>
|
||
</div>
|
||
</div>
|
||
<div class="section" id="why-doesn-t-python-have-a-with-statement-for-attribute-assignments">
|
||
<h2><a class="toc-backref" href="#id26">Why doesn’t Python have a “with” statement for attribute assignments?</a><a class="headerlink" href="#why-doesn-t-python-have-a-with-statement-for-attribute-assignments" title="Permalink to this headline">¶</a></h2>
|
||
<p>Python has a ‘with’ statement that wraps the execution of a block, calling code
|
||
on the entrance and exit from the block. Some language have a construct that
|
||
looks like this:</p>
|
||
<div class="highlight-python3 notranslate"><div class="highlight"><pre><span></span><span class="k">with</span> <span class="n">obj</span><span class="p">:</span>
|
||
<span class="n">a</span> <span class="o">=</span> <span class="mi">1</span> <span class="c1"># equivalent to obj.a = 1</span>
|
||
<span class="n">total</span> <span class="o">=</span> <span class="n">total</span> <span class="o">+</span> <span class="mi">1</span> <span class="c1"># obj.total = obj.total + 1</span>
|
||
</pre></div>
|
||
</div>
|
||
<p>In Python, such a construct would be ambiguous.</p>
|
||
<p>Other languages, such as Object Pascal, Delphi, and C++, use static types, so
|
||
it’s possible to know, in an unambiguous way, what member is being assigned
|
||
to. This is the main point of static typing – the compiler <em>always</em> knows the
|
||
scope of every variable at compile time.</p>
|
||
<p>Python uses dynamic types. It is impossible to know in advance which attribute
|
||
will be referenced at runtime. Member attributes may be added or removed from
|
||
objects on the fly. This makes it impossible to know, from a simple reading,
|
||
what attribute is being referenced: a local one, a global one, or a member
|
||
attribute?</p>
|
||
<p>For instance, take the following incomplete snippet:</p>
|
||
<div class="highlight-python3 notranslate"><div class="highlight"><pre><span></span><span class="k">def</span> <span class="nf">foo</span><span class="p">(</span><span class="n">a</span><span class="p">):</span>
|
||
<span class="k">with</span> <span class="n">a</span><span class="p">:</span>
|
||
<span class="nb">print</span><span class="p">(</span><span class="n">x</span><span class="p">)</span>
|
||
</pre></div>
|
||
</div>
|
||
<p>The snippet assumes that “a” must have a member attribute called “x”. However,
|
||
there is nothing in Python that tells the interpreter this. What should happen
|
||
if “a” is, let us say, an integer? If there is a global variable named “x”,
|
||
will it be used inside the with block? As you see, the dynamic nature of Python
|
||
makes such choices much harder.</p>
|
||
<p>The primary benefit of “with” and similar language features (reduction of code
|
||
volume) can, however, easily be achieved in Python by assignment. Instead of:</p>
|
||
<div class="highlight-python3 notranslate"><div class="highlight"><pre><span></span><span class="n">function</span><span class="p">(</span><span class="n">args</span><span class="p">)</span><span class="o">.</span><span class="n">mydict</span><span class="p">[</span><span class="n">index</span><span class="p">][</span><span class="n">index</span><span class="p">]</span><span class="o">.</span><span class="n">a</span> <span class="o">=</span> <span class="mi">21</span>
|
||
<span class="n">function</span><span class="p">(</span><span class="n">args</span><span class="p">)</span><span class="o">.</span><span class="n">mydict</span><span class="p">[</span><span class="n">index</span><span class="p">][</span><span class="n">index</span><span class="p">]</span><span class="o">.</span><span class="n">b</span> <span class="o">=</span> <span class="mi">42</span>
|
||
<span class="n">function</span><span class="p">(</span><span class="n">args</span><span class="p">)</span><span class="o">.</span><span class="n">mydict</span><span class="p">[</span><span class="n">index</span><span class="p">][</span><span class="n">index</span><span class="p">]</span><span class="o">.</span><span class="n">c</span> <span class="o">=</span> <span class="mi">63</span>
|
||
</pre></div>
|
||
</div>
|
||
<p>write this:</p>
|
||
<div class="highlight-python3 notranslate"><div class="highlight"><pre><span></span><span class="n">ref</span> <span class="o">=</span> <span class="n">function</span><span class="p">(</span><span class="n">args</span><span class="p">)</span><span class="o">.</span><span class="n">mydict</span><span class="p">[</span><span class="n">index</span><span class="p">][</span><span class="n">index</span><span class="p">]</span>
|
||
<span class="n">ref</span><span class="o">.</span><span class="n">a</span> <span class="o">=</span> <span class="mi">21</span>
|
||
<span class="n">ref</span><span class="o">.</span><span class="n">b</span> <span class="o">=</span> <span class="mi">42</span>
|
||
<span class="n">ref</span><span class="o">.</span><span class="n">c</span> <span class="o">=</span> <span class="mi">63</span>
|
||
</pre></div>
|
||
</div>
|
||
<p>This also has the side-effect of increasing execution speed because name
|
||
bindings are resolved at run-time in Python, and the second version only needs
|
||
to perform the resolution once.</p>
|
||
</div>
|
||
<div class="section" id="why-are-colons-required-for-the-if-while-def-class-statements">
|
||
<h2><a class="toc-backref" href="#id27">Why are colons required for the if/while/def/class statements?</a><a class="headerlink" href="#why-are-colons-required-for-the-if-while-def-class-statements" title="Permalink to this headline">¶</a></h2>
|
||
<p>The colon is required primarily to enhance readability (one of the results of
|
||
the experimental ABC language). Consider this:</p>
|
||
<div class="highlight-python3 notranslate"><div class="highlight"><pre><span></span><span class="k">if</span> <span class="n">a</span> <span class="o">==</span> <span class="n">b</span>
|
||
<span class="nb">print</span><span class="p">(</span><span class="n">a</span><span class="p">)</span>
|
||
</pre></div>
|
||
</div>
|
||
<p>versus</p>
|
||
<div class="highlight-python3 notranslate"><div class="highlight"><pre><span></span><span class="k">if</span> <span class="n">a</span> <span class="o">==</span> <span class="n">b</span><span class="p">:</span>
|
||
<span class="nb">print</span><span class="p">(</span><span class="n">a</span><span class="p">)</span>
|
||
</pre></div>
|
||
</div>
|
||
<p>Notice how the second one is slightly easier to read. Notice further how a
|
||
colon sets off the example in this FAQ answer; it’s a standard usage in English.</p>
|
||
<p>Another minor reason is that the colon makes it easier for editors with syntax
|
||
highlighting; they can look for colons to decide when indentation needs to be
|
||
increased instead of having to do a more elaborate parsing of the program text.</p>
|
||
</div>
|
||
<div class="section" id="why-does-python-allow-commas-at-the-end-of-lists-and-tuples">
|
||
<h2><a class="toc-backref" href="#id28">Why does Python allow commas at the end of lists and tuples?</a><a class="headerlink" href="#why-does-python-allow-commas-at-the-end-of-lists-and-tuples" title="Permalink to this headline">¶</a></h2>
|
||
<p>Python lets you add a trailing comma at the end of lists, tuples, and
|
||
dictionaries:</p>
|
||
<div class="highlight-python3 notranslate"><div class="highlight"><pre><span></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="p">(</span><span class="s1">'a'</span><span class="p">,</span> <span class="s1">'b'</span><span class="p">,</span> <span class="s1">'c'</span><span class="p">,)</span>
|
||
<span class="n">d</span> <span class="o">=</span> <span class="p">{</span>
|
||
<span class="s2">"A"</span><span class="p">:</span> <span class="p">[</span><span class="mi">1</span><span class="p">,</span> <span class="mi">5</span><span class="p">],</span>
|
||
<span class="s2">"B"</span><span class="p">:</span> <span class="p">[</span><span class="mi">6</span><span class="p">,</span> <span class="mi">7</span><span class="p">],</span> <span class="c1"># last trailing comma is optional but good style</span>
|
||
<span class="p">}</span>
|
||
</pre></div>
|
||
</div>
|
||
<p>There are several reasons to allow this.</p>
|
||
<p>When you have a literal value for a list, tuple, or dictionary spread across
|
||
multiple lines, it’s easier to add more elements because you don’t have to
|
||
remember to add a comma to the previous line. The lines can also be reordered
|
||
without creating a syntax error.</p>
|
||
<p>Accidentally omitting the comma can lead to errors that are hard to diagnose.
|
||
For example:</p>
|
||
<div class="highlight-python3 notranslate"><div class="highlight"><pre><span></span><span class="n">x</span> <span class="o">=</span> <span class="p">[</span>
|
||
<span class="s2">"fee"</span><span class="p">,</span>
|
||
<span class="s2">"fie"</span>
|
||
<span class="s2">"foo"</span><span class="p">,</span>
|
||
<span class="s2">"fum"</span>
|
||
<span class="p">]</span>
|
||
</pre></div>
|
||
</div>
|
||
<p>This list looks like it has four elements, but it actually contains three:
|
||
“fee”, “fiefoo” and “fum”. Always adding the comma avoids this source of error.</p>
|
||
<p>Allowing the trailing comma may also make programmatic code generation easier.</p>
|
||
</div>
|
||
</div>
|
||
|
||
|
||
</div>
|
||
</div>
|
||
</div>
|
||
<div class="sphinxsidebar" role="navigation" aria-label="main navigation">
|
||
<div class="sphinxsidebarwrapper">
|
||
<h3><a href="../contents.html">Table of Contents</a></h3>
|
||
<ul>
|
||
<li><a class="reference internal" href="#">Design and History FAQ</a><ul>
|
||
<li><a class="reference internal" href="#why-does-python-use-indentation-for-grouping-of-statements">Why does Python use indentation for grouping of statements?</a></li>
|
||
<li><a class="reference internal" href="#why-am-i-getting-strange-results-with-simple-arithmetic-operations">Why am I getting strange results with simple arithmetic operations?</a></li>
|
||
<li><a class="reference internal" href="#why-are-floating-point-calculations-so-inaccurate">Why are floating-point calculations so inaccurate?</a></li>
|
||
<li><a class="reference internal" href="#why-are-python-strings-immutable">Why are Python strings immutable?</a></li>
|
||
<li><a class="reference internal" href="#why-must-self-be-used-explicitly-in-method-definitions-and-calls">Why must ‘self’ be used explicitly in method definitions and calls?</a></li>
|
||
<li><a class="reference internal" href="#why-can-t-i-use-an-assignment-in-an-expression">Why can’t I use an assignment in an expression?</a></li>
|
||
<li><a class="reference internal" href="#why-does-python-use-methods-for-some-functionality-e-g-list-index-but-functions-for-other-e-g-len-list">Why does Python use methods for some functionality (e.g. list.index()) but functions for other (e.g. len(list))?</a></li>
|
||
<li><a class="reference internal" href="#why-is-join-a-string-method-instead-of-a-list-or-tuple-method">Why is join() a string method instead of a list or tuple method?</a></li>
|
||
<li><a class="reference internal" href="#how-fast-are-exceptions">How fast are exceptions?</a></li>
|
||
<li><a class="reference internal" href="#why-isn-t-there-a-switch-or-case-statement-in-python">Why isn’t there a switch or case statement in Python?</a></li>
|
||
<li><a class="reference internal" href="#can-t-you-emulate-threads-in-the-interpreter-instead-of-relying-on-an-os-specific-thread-implementation">Can’t you emulate threads in the interpreter instead of relying on an OS-specific thread implementation?</a></li>
|
||
<li><a class="reference internal" href="#why-can-t-lambda-expressions-contain-statements">Why can’t lambda expressions contain statements?</a></li>
|
||
<li><a class="reference internal" href="#can-python-be-compiled-to-machine-code-c-or-some-other-language">Can Python be compiled to machine code, C or some other language?</a></li>
|
||
<li><a class="reference internal" href="#how-does-python-manage-memory">How does Python manage memory?</a></li>
|
||
<li><a class="reference internal" href="#why-doesn-t-cpython-use-a-more-traditional-garbage-collection-scheme">Why doesn’t CPython use a more traditional garbage collection scheme?</a></li>
|
||
<li><a class="reference internal" href="#why-isn-t-all-memory-freed-when-cpython-exits">Why isn’t all memory freed when CPython exits?</a></li>
|
||
<li><a class="reference internal" href="#why-are-there-separate-tuple-and-list-data-types">Why are there separate tuple and list data types?</a></li>
|
||
<li><a class="reference internal" href="#how-are-lists-implemented-in-cpython">How are lists implemented in CPython?</a></li>
|
||
<li><a class="reference internal" href="#how-are-dictionaries-implemented-in-cpython">How are dictionaries implemented in CPython?</a></li>
|
||
<li><a class="reference internal" href="#why-must-dictionary-keys-be-immutable">Why must dictionary keys be immutable?</a></li>
|
||
<li><a class="reference internal" href="#why-doesn-t-list-sort-return-the-sorted-list">Why doesn’t list.sort() return the sorted list?</a></li>
|
||
<li><a class="reference internal" href="#how-do-you-specify-and-enforce-an-interface-spec-in-python">How do you specify and enforce an interface spec in Python?</a></li>
|
||
<li><a class="reference internal" href="#why-is-there-no-goto">Why is there no goto?</a></li>
|
||
<li><a class="reference internal" href="#why-can-t-raw-strings-r-strings-end-with-a-backslash">Why can’t raw strings (r-strings) end with a backslash?</a></li>
|
||
<li><a class="reference internal" href="#why-doesn-t-python-have-a-with-statement-for-attribute-assignments">Why doesn’t Python have a “with” statement for attribute assignments?</a></li>
|
||
<li><a class="reference internal" href="#why-are-colons-required-for-the-if-while-def-class-statements">Why are colons required for the if/while/def/class statements?</a></li>
|
||
<li><a class="reference internal" href="#why-does-python-allow-commas-at-the-end-of-lists-and-tuples">Why does Python allow commas at the end of lists and tuples?</a></li>
|
||
</ul>
|
||
</li>
|
||
</ul>
|
||
|
||
<h4>Previous topic</h4>
|
||
<p class="topless"><a href="programming.html"
|
||
title="previous chapter">Programming FAQ</a></p>
|
||
<h4>Next topic</h4>
|
||
<p class="topless"><a href="library.html"
|
||
title="next chapter">Library and Extension FAQ</a></p>
|
||
<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/3.7/Doc/faq/design.rst"
|
||
rel="nofollow">Show Source
|
||
</a>
|
||
</li>
|
||
</ul>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
<div class="clearer"></div>
|
||
</div>
|
||
<div class="related" role="navigation" aria-label="related navigation">
|
||
<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="library.html" title="Library and Extension FAQ"
|
||
>next</a> |</li>
|
||
<li class="right" >
|
||
<a href="programming.html" title="Programming FAQ"
|
||
>previous</a> |</li>
|
||
<li><img src="../_static/py.png" alt=""
|
||
style="vertical-align: middle; margin-top: -1px"/></li>
|
||
<li><a href="https://www.python.org/">Python</a> »</li>
|
||
<li>
|
||
<span class="language_switcher_placeholder">en</span>
|
||
<span class="version_switcher_placeholder">3.7.4</span>
|
||
<a href="../index.html">Documentation </a> »
|
||
</li>
|
||
|
||
<li class="nav-item nav-item-1"><a href="index.html" >Python Frequently Asked Questions</a> »</li>
|
||
<li class="right">
|
||
|
||
|
||
<div class="inline-search" style="display: none" role="search">
|
||
<form class="inline-search" action="../search.html" method="get">
|
||
<input placeholder="Quick search" type="text" name="q" />
|
||
<input type="submit" value="Go" />
|
||
<input type="hidden" name="check_keywords" value="yes" />
|
||
<input type="hidden" name="area" value="default" />
|
||
</form>
|
||
</div>
|
||
<script type="text/javascript">$('.inline-search').show(0);</script>
|
||
|
|
||
</li>
|
||
|
||
</ul>
|
||
</div>
|
||
<div class="footer">
|
||
© <a href="../copyright.html">Copyright</a> 2001-2019, Python Software Foundation.
|
||
<br />
|
||
The Python Software Foundation is a non-profit corporation.
|
||
<a href="https://www.python.org/psf/donations/">Please donate.</a>
|
||
<br />
|
||
Last updated on Jul 13, 2019.
|
||
<a href="../bugs.html">Found a bug</a>?
|
||
<br />
|
||
Created using <a href="http://sphinx.pocoo.org/">Sphinx</a> 2.0.1.
|
||
</div>
|
||
|
||
</body>
|
||
</html> |