
Design and History FAQ
**********************


Why does Python use indentation for grouping of statements?
===========================================================

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 awhile.

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:

   if (x <= y)
           x++;
           y--;
   z++;

Only the ``x++`` 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 ``y``
is being decremented even for ``x > y``.

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.

Many coding styles place begin/end brackets on a line by themself.
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.


Why am I getting strange results with simple arithmetic operations?
===================================================================

See the next question.


Why are floating point calculations so inaccurate?
==================================================

People are often very surprised by results like this:

   >>> 1.2-1.0
   0.199999999999999996

and think it is a bug in Python. It's not.  This has nothing to do
with Python, but with how the underlying C platform handles floating
point numbers, and ultimately with the inaccuracies introduced when
writing down numbers as a string of a fixed number of digits.

The internal representation of floating point numbers uses a fixed
number of binary digits to represent a decimal number.  Some decimal
numbers can't be represented exactly in binary, resulting in small
roundoff errors.

In decimal math, there are many numbers that can't be represented with
a fixed number of decimal digits, e.g.  1/3 = 0.3333333333.......

In base 2, 1/2 = 0.1, 1/4 = 0.01, 1/8 = 0.001, etc.  .2 equals 2/10
equals 1/5, resulting in the binary fractional number
0.001100110011001...

Floating point numbers only have 32 or 64 bits of precision, so the
digits are cut off at some point, and the resulting number is
0.199999999999999996 in decimal, not 0.2.

A floating point number's ``repr()`` function prints as many digits
are necessary to make ``eval(repr(f)) == f`` true for any float f.
The ``str()`` function prints fewer digits and this often results in
the more sensible number that was probably intended:

   >>> 0.2
   0.20000000000000001
   >>> print 0.2
   0.2

One of the consequences of this is that it is error-prone to compare
the result of some computation to a float with ``==``. Tiny
inaccuracies may mean that ``==`` fails.  Instead, you have to check
that the difference between the two numbers is less than a certain
threshold:

   epsilon = 0.0000000000001 # Tiny allowed error
   expected_result = 0.4

   if expected_result-epsilon <= computation() <= expected_result+epsilon:
       ...

Please see the chapter on *floating point arithmetic* in the Python
tutorial for more information.


Why are Python strings immutable?
=================================

There are several advantages.

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.

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.


Why must 'self' be used explicitly in method definitions and calls?
===================================================================

The idea was borrowed from Modula-3.  It turns out to be very useful,
for a variety of reasons.

First, it's more obvious that you are using a method or instance
attribute instead of a local variable.  Reading ``self.x`` or
``self.meth()`` 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 ``m_`` prefix, so
this explicitness is still useful in those languages, too.

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 ``::`` operator -- in Python
you can write baseclass.methodname(self, <argument list>).  This is
particularly useful for ``__init__()`` 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.

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 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 "self.var" solves this nicely.  Similarly, for using instance
variables, having to write "self.var" 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.


Why can't I use an assignment in an expression?
===============================================

Many people used to C or Perl complain that they want to use this C
idiom:

   while (line = readline(f)) {
       // do something with line
   }

where in Python you're forced to write this:

   while True:
       line = f.readline()
       if not line:
           break
       ... # do something with line

The reason for not allowing assignment in Python expressions is a
common, hard-to-find bug in those other languages, caused by this
construct:

   if (x = 0) {
       // error handling
   }
   else {
       // code that only works for nonzero x
   }

The error is a simple typo: ``x = 0``, which assigns 0 to the variable
``x``, was written while the comparison ``x == 0`` is certainly what
was intended.

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.

An interesting phenomenon is that most experienced Python programmers
recognize the ``while True`` 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.

There's an alternative way of spelling this that seems attractive but
is generally less robust than the "while True" solution:

   line = f.readline()
   while line:
       ... # do something with line...
       line = f.readline()

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
``sys.stdin.readline()``) you have to remember to change two places in
your program -- the second occurrence is hidden at the bottom of the
loop.

The best approach is to use iterators, making it possible to loop
through objects using the ``for`` statement.  For example, in the
current version of Python file objects support the iterator protocol,
so you can now write simply:

   for line in f:
       ... # do something with line...


Why does Python use methods for some functionality (e.g. list.index()) but functions for other (e.g. len(list))?
================================================================================================================

The major reason is history. Functions were used for those operations
that were generic for a group of types and which were intended to work
even for objects that didn't have methods at all (e.g. tuples).  It is
also convenient to have a function that can readily be applied to an
amorphous collection of objects when you use the functional features
of Python (``map()``, ``apply()`` et al).

In fact, implementing ``len()``, ``max()``, ``min()`` as a built-in
function is actually less code than implementing them as methods for
each type.  One can quibble about individual cases but it's a part of
Python, and it's too late to make such fundamental changes now. The
functions have to remain to avoid massive code breakage.

Note that for string operations Python has moved from external
functions (the ``string`` module) to methods.  However, ``len()`` is
still a function.


Why is join() a string method instead of a list or tuple method?
================================================================

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:

   ", ".join(['1', '2', '4', '8', '16'])

which gives the result:

   "1, 2, 4, 8, 16"

There are two common arguments against this usage.

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.

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 ``split()`` as a string method, since in that case it is
easy to see that

   "1, 2, 4, 8, 16".split(", ")

is an instruction to a string literal to return the substrings
delimited by the given separator (or, by default, arbitrary runs of
white space).  In this case a Unicode string returns a list of Unicode
strings, an ASCII string returns a list of ASCII strings, and everyone
is happy.

``join()`` 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.

Because this is a string method it can work for Unicode strings as
well as plain ASCII strings.  If ``join()`` were a method of the
sequence types then the sequence types would have to decide which type
of string to return depending on the type of the separator.

If none of these arguments persuade you, then for the moment you can
continue to use the ``join()`` function from the string module, which
allows you to write

   string.join(['1', '2', '4', '8', '16'], ", ")


How fast are exceptions?
========================

A try/except block is extremely efficient.  Actually catching an
exception is expensive.  In versions of Python prior to 2.0 it was
common to use this idiom:

   try:
       value = dict[key]
   except KeyError:
       dict[key] = getvalue(key)
       value = dict[key]

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:

   if dict.has_key(key):
       value = dict[key]
   else:
       dict[key] = getvalue(key)
       value = dict[key]

(In Python 2.0 and higher, you can code this as ``value =
dict.setdefault(key, getvalue(key))``.)


Why isn't there a switch or case statement in Python?
=====================================================

You can do this easily enough with a sequence of ``if... elif...
elif... else``. There have been some proposals for switch statement
syntax, but there is no consensus (yet) on whether and how to do range
tests.  See **PEP 275** for complete details and the current status.

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:

   def function_1(...):
       ...

   functions = {'a': function_1,
                'b': function_2,
                'c': self.method_1, ...}

   func = functions[value]
   func()

For calling methods on objects, you can simplify yet further by using
the ``getattr()`` built-in to retrieve methods with a particular name:

   def visit_a(self, ...):
       ...
   ...

   def dispatch(self, value):
       method_name = 'visit_' + str(value)
       method = getattr(self, method_name)
       method()

It's suggested that you use a prefix for the method names, such as
``visit_`` 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.


Can't you emulate threads in the interpreter instead of relying on an OS-specific thread implementation?
========================================================================================================

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.

Answer 2: Fortunately, there is Stackless Python, which has a
completely redesigned interpreter loop that avoids the C stack. It's
still experimental but looks very promising.  Although it is binary
compatible with standard Python, it's still unclear whether Stackless
will make it into the core -- maybe it's just too revolutionary.


Why can't lambda forms contain statements?
==========================================

Python lambda forms 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.

Functions are already first class objects in Python, and can be
declared in a local scope.  Therefore the only advantage of using a
lambda form 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 form yields) is assigned!


Can Python be compiled to machine code, C or some other language?
=================================================================

Not easily.  Python's high level data types, dynamic typing of objects
and run-time invocation of the interpreter (using ``eval()`` or
``exec``) together mean that a "compiled" Python program would
probably consist mostly of calls into the Python run-time system, even
for seemingly simple operations like ``x+1``.

Several projects described in the Python newsgroup or at past Python
conferences have shown that this approach is feasible, although the
speedups reached so far are only modest (e.g. 2x).  Jython uses the
same strategy for compiling to Java bytecode.  (Jim Hugunin has
demonstrated that in combination with whole-program analysis, speedups
of 1000x are feasible for small demo programs.  See the proceedings
from the 1997 Python conference for more information.)

Internally, Python source code is always translated into a bytecode
representation, and this bytecode is then executed by the Python
virtual machine.  In order to avoid the overhead of repeatedly parsing
and translating modules that rarely change, this byte code is written
into a file whose name ends in ".pyc" whenever a module is parsed.
When the corresponding .py file is changed, it is parsed and
translated again and the .pyc file is rewritten.

There is no performance difference once the .pyc file has been loaded,
as the bytecode read from the .pyc file is exactly the same as the
bytecode created by direct translation.  The only difference is that
loading code from a .pyc file is faster than parsing and translating a
.py file, so the presence of precompiled .pyc files improves the
start-up time of Python scripts.  If desired, the Lib/compileall.py
module can be used to create valid .pyc files for a given set of
modules.

Note that the main script executed by Python, even if its filename
ends in .py, is not compiled to a .pyc file.  It is compiled to
bytecode, but the bytecode is not saved to a file.  Usually main
scripts are quite short, so this doesn't cost much speed.

There are also several programs which make it easier to intermingle
Python and C code in various ways to increase performance.  See, for
example, Psyco, Pyrex, PyInline, Py2Cmod, and Weave.


How does Python manage memory?
==============================

The details of Python memory management depend on the implementation.
The standard C implementation of Python 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 ``gc`` module provides functions to perform a garbage collection,
obtain debugging statistics, and tune the collector's parameters.

Jython relies on the Java runtime so the JVM's garbage collector is
used.  This difference can cause some subtle porting problems if your
Python code depends on the behavior of the reference counting
implementation.

Sometimes objects get stuck in tracebacks temporarily and hence are
not deallocated when you might expect.  Clear the tracebacks with:

   import sys
   sys.exc_clear()
   sys.exc_traceback = sys.last_traceback = None

Tracebacks are used for reporting errors, implementing debuggers and
related things.  They contain a portion of the program state extracted
during the handling of an exception (usually the most recent
exception).

In the absence of circularities and tracebacks, Python programs need
not explicitly manage memory.

Why doesn't Python use a more traditional garbage collection scheme?
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 *most* 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.)

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 *own*
substitute for malloc() and free(), and may not want Python's.  Right
now, Python works with anything that implements malloc() and free()
properly.

In Jython, the following code (which is fine in CPython) will probably
run out of file descriptors long before it runs out of memory:

   for file in <very long list of files>:
       f = open(file)
       c = f.read(1)

Using the current reference counting and destructor scheme, each new
assignment to f closes the previous file.  Using GC, this is not
guaranteed.  If you want to write code that will work with any Python
implementation, you should explicitly close the file; this will work
regardless of GC:

   for file in <very long list of files>:
       f = open(file)
       c = f.read(1)
       f.close()


Why isn't all memory freed when Python exits?
=============================================

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.

If you want to force Python to delete certain things on deallocation
use the ``atexit`` module to run a function that will force those
deletions.


Why are there separate tuple and list data types?
=================================================

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.

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,
``os.listdir('.')`` 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.

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.


How are lists implemented?
==========================

Python'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.

This makes indexing a list ``a[i]`` an operation whose cost is
independent of the size of the list or the value of the index.

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.


How are dictionaries implemented?
=================================

Python'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.

Dictionaries work by computing a hash code for each key stored in the
dictionary using the ``hash()`` built-in function.  The hash code
varies widely depending on the key; for example, "Python" hashes to
-539294296 while "python", a string that differs by a single bit,
hashes 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 computer
science notation -- to retrieve a key.  It also means that no sorted
order of the keys is maintained, and traversing the array as the
``.keys()`` and ``.items()`` do will output the dictionary's content
in some arbitrary jumbled order.


Why must dictionary keys be immutable?
======================================

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.

If you want a dictionary indexed with a list, simply convert the list
to a tuple first; the function ``tuple(L)`` creates a tuple with the
same entries as the list ``L``.  Tuples are immutable and can
therefore be used as dictionary keys.

Some unacceptable solutions that have been proposed:

* 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.:

     d = {[1,2]: '12'}
     print d[[1,2]]

  would raise a KeyError exception because the id of the ``[1,2]``
  used in the second line differs from that in the first line.  In
  other words, dictionary keys should be compared using ``==``, not
  using ``is``.

* 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.

* 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 ``d.keys()`` is
  usable as a key of the dictionary.

* 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.

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 ``__cmp_()`` and a ``__hash__()`` 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).

   class ListWrapper:
       def __init__(self, the_list):
           self.the_list = the_list
       def __cmp__(self, other):
           return self.the_list == other.the_list
       def __hash__(self):
           l = self.the_list
           result = 98767 - len(l)*555
           for i in range(len(l)):
               try:
                   result = result + (hash(l[i]) % 9999999) * 1001 + i
               except:
                   result = (result % 7777777) + i * 333
           return result

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.

Furthermore it must always be the case that if ``o1 == o2`` (ie
``o1.__cmp__(o2) == 0``) then ``hash(o1) == hash(o2)`` (ie,
``o1.__hash__() == o2.__hash__()``), 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.

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.


Why doesn't list.sort() return the sorted list?
===============================================

In situations where performance matters, making a copy of the list
just to sort it would be wasteful. Therefore, ``list.sort()`` 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.

In Python 2.4 a new builtin -- ``sorted()`` -- has been added.  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:

   for key in sorted(dict.iterkeys()):
       ... # do whatever with dict[key]...


How do you specify and enforce an interface spec in Python?
===========================================================

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.

Python 2.6 adds an ``abc`` module that lets you define Abstract Base
Classes (ABCs).  You can then use ``isinstance()`` and
``issubclass()`` to check whether an instance or a class implements a
particular ABC.  The ``collections`` modules defines a set of useful
ABCs such as ``Iterable``, ``Container``, and ``MutableMapping``.

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.

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 ``doctest`` and ``unittest`` modules or third-party
test frameworks can be used to construct exhaustive test suites that
exercise every line of code in a module.

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
``append()`` method is expected to add new elements to the end of some
internal list; an interface specification cannot test that your
``append()`` implementation will actually do this correctly, but it's
trivial to check this property in a test suite.

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.


Why are default values shared between objects?
==============================================

This type of bug commonly bites neophyte programmers.  Consider this
function:

   def foo(D={}):  # Danger: shared reference to one dict for all calls
       ... compute something ...
       D[key] = value
       return D

The first time you call this function, ``D`` contains a single item.
The second time, ``D`` contains two items because when ``foo()``
begins executing, ``D`` starts out with an item already in it.

It is often expected that a function call creates new objects for
default values. This is not what happens. Default values are created
exactly once, when the function is defined.  If that object is
changed, like the dictionary in this example, subsequent calls to the
function will refer to this changed object.

By definition, immutable objects such as numbers, strings, tuples, and
``None``, are safe from change. Changes to mutable objects such as
dictionaries, lists, and class instances can lead to confusion.

Because of this feature, it is good programming practice to not use
mutable objects as default values.  Instead, use ``None`` as the
default value and inside the function, check if the parameter is
``None`` and create a new list/dictionary/whatever if it is.  For
example, don't write:

   def foo(dict={}):
       ...

but:

   def foo(dict=None):
       if dict is None:
           dict = {} # create a new dict for local namespace

This feature can be useful.  When you have a function that's time-
consuming to compute, a common technique is to cache the parameters
and the resulting value of each call to the function, and return the
cached value if the same value is requested again.  This is called
"memoizing", and can be implemented like this:

   # Callers will never provide a third parameter for this function.
   def expensive (arg1, arg2, _cache={}):
       if _cache.has_key((arg1, arg2)):
           return _cache[(arg1, arg2)]

       # Calculate the value
       result = ... expensive computation ...
       _cache[(arg1, arg2)] = result           # Store result in the cache
       return result

You could use a global variable containing a dictionary instead of the
default value; it's a matter of taste.


Why is there no goto?
=====================

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:

   class label: pass # declare a label

   try:
        ...
        if (condition): raise label() # goto label
        ...
   except label: # where to goto
        pass
   ...

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.


Why can't raw strings (r-strings) end with a backslash?
=======================================================

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.

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.

If you're trying to build Windows pathnames, note that all Windows
system calls accept forward slashes too:

   f = open("/mydir/file.txt") # works fine!

If you're trying to build a pathname for a DOS command, try e.g. one
of

   dir = r"\this\is\my\dos\dir" "\\"
   dir = r"\this\is\my\dos\dir\ "[:-1]
   dir = "\\this\\is\\my\\dos\\dir\\"


Why doesn't Python have a "with" statement for attribute assignments?
=====================================================================

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:

   with obj:
       a = 1    # equivalent to obj.a = 1
       total = total + 1   # obj.total = obj.total + 1

In Python, such a construct would be ambiguous.

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 *always* knows the scope of every variable at compile time.

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?

For instance, take the following incomplete snippet:

   def foo(a):
       with a:
           print x

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.

The primary benefit of "with" and similar language features (reduction
of code volume) can, however, easily be achieved in Python by
assignment.  Instead of:

   function(args).dict[index][index].a = 21
   function(args).dict[index][index].b = 42
   function(args).dict[index][index].c = 63

write this:

   ref = function(args).dict[index][index]
   ref.a = 21
   ref.b = 42
   ref.c = 63

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.  If the referenced
object does not have a, b and c attributes, of course, the end result
is still a run-time exception.


Why are colons required for the if/while/def/class statements?
==============================================================

The colon is required primarily to enhance readability (one of the
results of the experimental ABC language).  Consider this:

   if a == b
       print a

versus

   if a == b:
       print a

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.

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.


Why does Python allow commas at the end of lists and tuples?
============================================================

Python lets you add a trailing comma at the end of lists, tuples, and
dictionaries:

   [1, 2, 3,]
   ('a', 'b', 'c',)
   d = {
       "A": [1, 5],
       "B": [6, 7],  # last trailing comma is optional but good style
   }

There are several reasons to allow this.

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 sorted in your editor without creating a syntax error.

Accidentally omitting the comma can lead to errors that are hard to
diagnose. For example:

   x = [
     "fee",
     "fie"
     "foo",
     "fum"
   ]

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.

Allowing the trailing comma may also make programmatic code generation
easier.
