Programming FAQ¶
General Questions¶
Is there a source code level debugger with breakpoints, single-stepping, etc.?¶
Yes.
Several debuggers for Python are described below, and the built-in function
breakpoint()
allows you to drop into any of them.
The pdb module is a simple but adequate console-mode debugger for Python. It is
part of the standard Python library, and is documented in the Library
Reference Manual
. You can also write your own debugger by using the code
for pdb as an example.
The IDLE interactive development environment, which is part of the standard Python distribution (normally available as Tools/scripts/idle3), includes a graphical debugger.
PythonWin is a Python IDE that includes a GUI debugger based on pdb. The PythonWin debugger colors breakpoints and has quite a few cool features such as debugging non-PythonWin programs. PythonWin is available as part of pywin32 project and as a part of the ActivePython distribution.
Eric is an IDE built on PyQt and the Scintilla editing component.
trepan3k is a gdb-like debugger.
Visual Studio Code is an IDE with debugging tools that integrates with version-control software.
There are a number of commercial Python IDEs that include graphical debuggers. They include:
Are there tools to help find bugs or perform static analysis?¶
Yes.
Pylint and Pyflakes do basic checking that will help you catch bugs sooner.
Static type checkers such as Mypy, Pyre, and Pytype can check type hints in Python source code.
How can I create a stand-alone binary from a Python script?¶
You don’t need the ability to compile Python to C code if all you want is a stand-alone program that users can download and run without having to install the Python distribution first. There are a number of tools that determine the set of modules required by a program and bind these modules together with a Python binary to produce a single executable.
One is to use the freeze tool, which is included in the Python source tree as Tools/freeze. It converts Python byte code to C arrays; with a C compiler you can embed all your modules into a new program, which is then linked with the standard Python modules.
It works by scanning your source recursively for import statements (in both forms) and looking for the modules in the standard Python path as well as in the source directory (for built-in modules). It then turns the bytecode for modules written in Python into C code (array initializers that can be turned into code objects using the marshal module) and creates a custom-made config file that only contains those built-in modules which are actually used in the program. It then compiles the generated C code and links it with the rest of the Python interpreter to form a self-contained binary which acts exactly like your script.
The following packages can help with the creation of console and GUI executables:
Nuitka (Cross-platform)
PyInstaller (Cross-platform)
PyOxidizer (Cross-platform)
cx_Freeze (Cross-platform)
py2app (macOS only)
py2exe (Windows only)
Are there coding standards or a style guide for Python programs?¶
Yes. The coding style required for standard library modules is documented as PEP 8.
Core Language¶
Why am I getting an UnboundLocalError when the variable has a value?¶
It can be a surprise to get the UnboundLocalError
in previously working
code when it is modified by adding an assignment statement somewhere in
the body of a function.
This code:
>>> x = 10
>>> def bar():
... print(x)
...
>>> bar()
10
works, but this code:
>>> x = 10
>>> def foo():
... print(x)
... x += 1
results in an UnboundLocalError
:
>>> foo()
Traceback (most recent call last):
...
UnboundLocalError: local variable 'x' referenced before assignment
This is because when you make an assignment to a variable in a scope, that
variable becomes local to that scope and shadows any similarly named variable
in the outer scope. Since the last statement in foo assigns a new value to
x
, the compiler recognizes it as a local variable. Consequently when the
earlier print(x)
attempts to print the uninitialized local variable and
an error results.
In the example above you can access the outer scope variable by declaring it global:
>>> x = 10
>>> def foobar():
... global x
... print(x)
... x += 1
...
>>> foobar()
10
This explicit declaration is required in order to remind you that (unlike the superficially analogous situation with class and instance variables) you are actually modifying the value of the variable in the outer scope:
>>> print(x)
11
You can do a similar thing in a nested scope using the nonlocal
keyword:
>>> def foo():
... x = 10
... def bar():
... nonlocal x
... print(x)
... x += 1
... bar()
... print(x)
...
>>> foo()
10
11
What are the rules for local and global variables in Python?¶
In Python, variables that are only referenced inside a function are implicitly global. If a variable is assigned a value anywhere within the function’s body, it’s assumed to be a local unless explicitly declared as global.
Though a bit surprising at first, a moment’s consideration explains this. On
one hand, requiring global
for assigned variables provides a bar
against unintended side-effects. On the other hand, if global
was required
for all global references, you’d be using global
all the time. You’d have
to declare as global every reference to a built-in function or to a component of
an imported module. This clutter would defeat the usefulness of the global
declaration for identifying side-effects.
Why do lambdas defined in a loop with different values all return the same result?¶
Assume you use a for loop to define a few different lambdas (or even plain functions), e.g.:
>>> squares = []
>>> for x in range(5):
... squares.append(lambda: x**2)
This gives you a list that contains 5 lambdas that calculate x**2
. You
might expect that, when called, they would return, respectively, 0
, 1
,
4
, 9
, and 16
. However, when you actually try you will see that
they all return 16
:
>>> squares[2]()
16
>>> squares[4]()
16
This happens because x
is not local to the lambdas, but is defined in
the outer scope, and it is accessed when the lambda is called — not when it
is defined. At the end of the loop, the value of x
is 4
, so all the
functions now return 4**2
, i.e. 16
. You can also verify this by
changing the value of x
and see how the results of the lambdas change:
>>> x = 8
>>> squares[2]()
64
In order to avoid this, you need to save the values in variables local to the
lambdas, so that they don’t rely on the value of the global x
:
>>> squares = []
>>> for x in range(5):
... squares.append(lambda n=x: n**2)
Here, n=x
creates a new variable n
local to the lambda and computed
when the lambda is defined so that it has the same value that x
had at
that point in the loop. This means that the value of n
will be 0
in the first lambda, 1
in the second, 2
in the third, and so on.
Therefore each lambda will now return the correct result:
>>> squares[2]()
4
>>> squares[4]()
16
Note that this behaviour is not peculiar to lambdas, but applies to regular functions too.
What are the “best practices” for using import in a module?¶
In general, don’t use from modulename import *
. Doing so clutters the
importer’s namespace, and makes it much harder for linters to detect undefined
names.
Import modules at the top of a file. Doing so makes it clear what other modules your code requires and avoids questions of whether the module name is in scope. Using one import per line makes it easy to add and delete module imports, but using multiple imports per line uses less screen space.
It’s good practice if you import modules in the following order:
third-party library modules (anything installed in Python’s site-packages directory) – e.g.
dateutil
,requests
,PIL.Image
locally developed modules
It is sometimes necessary to move imports to a function or class to avoid problems with circular imports. Gordon McMillan says:
Circular imports are fine where both modules use the “import <module>” form of import. They fail when the 2nd module wants to grab a name out of the first (“from module import name”) and the import is at the top level. That’s because names in the 1st are not yet available, because the first module is busy importing the 2nd.
In this case, if the second module is only used in one function, then the import can easily be moved into that function. By the time the import is called, the first module will have finished initializing, and the second module can do its import.
It may also be necessary to move imports out of the top level of code if some of the modules are platform-specific. In that case, it may not even be possible to import all of the modules at the top of the file. In this case, importing the correct modules in the corresponding platform-specific code is a good option.
Only move imports into a local scope, such as inside a function definition, if
it’s necessary to solve a problem such as avoiding a circular import or are
trying to reduce the initialization time of a module. This technique is
especially helpful if many of the imports are unnecessary depending on how the
program executes. You may also want to move imports into a function if the
modules are only ever used in that function. Note that loading a module the
first time may be expensive because of the one time initialization of the
module, but loading a module multiple times is virtually free, costing only a
couple of dictionary lookups. Even if the module name has gone out of scope,
the module is probably available in sys.modules
.
How can I pass optional or keyword parameters from one function to another?¶
Collect the arguments using the *
and **
specifiers in the function’s
parameter list; this gives you the positional arguments as a tuple and the
keyword arguments as a dictionary. You can then pass these arguments when
calling another function by using *
and **
:
def f(x, *args, **kwargs):
...
kwargs['width'] = '14.3c'
...
g(x, *args, **kwargs)
What is the difference between arguments and parameters?¶
Parameters are defined by the names that appear in a function definition, whereas arguments are the values actually passed to a function when calling it. Parameters define what kind of arguments a function can accept. For example, given the function definition:
def func(foo, bar=None, **kwargs):
pass
foo, bar and kwargs are parameters of func
. However, when calling
func
, for example:
func(42, bar=314, extra=somevar)
the values 42
, 314
, and somevar
are arguments.
Why did changing list ‘y’ also change list ‘x’?¶
If you wrote code like:
>>> x = []
>>> y = x
>>> y.append(10)
>>> y
[10]
>>> x
[10]
you might be wondering why appending an element to y
changed x
too.
There are two factors that produce this result:
Variables are simply names that refer to objects. Doing
y = x
doesn’t create a copy of the list – it creates a new variabley
that refers to the same objectx
refers to. This means that there is only one object (the list), and bothx
andy
refer to it.Lists are mutable, which means that you can change their content.
After the call to append()
, the content of the mutable object has
changed from []
to [10]
. Since both the variables refer to the same
object, using either name accesses the modified value [10]
.
If we instead assign an immutable object to x
:
>>> x = 5 # ints are immutable
>>> y = x
>>> x = x + 1 # 5 can't be mutated, we are creating a new object here
>>> x
6
>>> y
5
we can see that in this case x
and y
are not equal anymore. This is
because integers are immutable, and when we do x = x + 1
we are not
mutating the int 5
by incrementing its value; instead, we are creating a
new object (the int 6
) and assigning it to x
(that is, changing which
object x
refers to). After this assignment we have two objects (the ints
6
and 5
) and two variables that refer to them (x
now refers to
6
but y
still refers to 5
).
Some operations (for example y.append(10)
and y.sort()
) mutate the
object, whereas superficially similar operations (for example y = y + [10]
and sorted(y)
) create a new object. In general in Python (and in all cases
in the standard library) a method that mutates an object will return None
to help avoid getting the two types of operations confused. So if you
mistakenly write y.sort()
thinking it will give you a sorted copy of y
,
you’ll instead end up with None
, which will likely cause your program to
generate an easily diagnosed error.
However, there is one class of operations where the same operation sometimes
has different behaviors with different types: the augmented assignment
operators. For example, +=
mutates lists but not tuples or ints (a_list
+= [1, 2, 3]
is equivalent to a_list.extend([1, 2, 3])
and mutates
a_list
, whereas some_tuple += (1, 2, 3)
and some_int += 1
create
new objects).
In other words:
If we have a mutable object (
list
,dict
,set
, etc.), we can use some specific operations to mutate it and all the variables that refer to it will see the change.If we have an immutable object (
str
,int
,tuple
, etc.), all the variables that refer to it will always see the same value, but operations that transform that value into a new value always return a new object.
If you want to know if two variables refer to the same object or not, you can
use the is
operator, or the built-in function id()
.
How do I write a function with output parameters (call by reference)?¶
Remember that arguments are passed by assignment in Python. Since assignment just creates references to objects, there’s no alias between an argument name in the caller and callee, and so no call-by-reference per se. You can achieve the desired effect in a number of ways.
By returning a tuple of the results:
>>> def func1(a, b): ... a = 'new-value' # a and b are local names ... b = b + 1 # assigned to new objects ... return a, b # return new values ... >>> x, y = 'old-value', 99 >>> func1(x, y) ('new-value', 100)
This is almost always the clearest solution.
By using global variables. This isn’t thread-safe, and is not recommended.
By passing a mutable (changeable in-place) object:
>>> def func2(a): ... a[0] = 'new-value' # 'a' references a mutable list ... a[1] = a[1] + 1 # changes a shared object ... >>> args = ['old-value', 99] >>> func2(args) >>> args ['new-value', 100]
By passing in a dictionary that gets mutated:
>>> def func3(args): ... args['a'] = 'new-value' # args is a mutable dictionary ... args['b'] = args['b'] + 1 # change it in-place ... >>> args = {'a': 'old-value', 'b': 99} >>> func3(args) >>> args {'a': 'new-value', 'b': 100}
Or bundle up values in a class instance:
>>> class Namespace: ... def __init__(self, /, **args): ... for key, value in args.items(): ... setattr(self, key, value) ... >>> def func4(args): ... args.a = 'new-value' # args is a mutable Namespace ... args.b = args.b + 1 # change object in-place ... >>> args = Namespace(a='old-value', b=99) >>> func4(args) >>> vars(args) {'a': 'new-value', 'b': 100}
There’s almost never a good reason to get this complicated.
Your best choice is to return a tuple containing the multiple results.
How do you make a higher order function in Python?¶
You have two choices: you can use nested scopes or you can use callable objects.
For example, suppose you wanted to define linear(a,b)
which returns a
function f(x)
that computes the value a*x+b
. Using nested scopes:
def linear(a, b):
def result(x):
return a * x + b
return result
Or using a callable object:
class linear:
def __init__(self, a, b):
self.a, self.b = a, b
def __call__(self, x):
return self.a * x + self.b
In both cases,
taxes = linear(0.3, 2)
gives a callable object where taxes(10e6) == 0.3 * 10e6 + 2
.
The callable object approach has the disadvantage that it is a bit slower and results in slightly longer code. However, note that a collection of callables can share their signature via inheritance:
class exponential(linear):
# __init__ inherited
def __call__(self, x):
return self.a * (x ** self.b)
Object can encapsulate state for several methods:
class counter:
value = 0
def set(self, x):
self.value = x
def up(self):
self.value = self.value + 1
def down(self):
self.value = self.value - 1
count = counter()
inc, dec, reset = count.up, count.down, count.set
Here inc()
, dec()
and reset()
act like functions which share the
same counting variable.
How do I copy an object in Python?¶
In general, try copy.copy()
or copy.deepcopy()
for the general case.
Not all objects can be copied, but most can.
Some objects can be copied more easily. Dictionaries have a copy()
method:
newdict = olddict.copy()
Sequences can be copied by slicing:
new_l = l[:]
How can I find the methods or attributes of an object?¶
For an instance x
of a user-defined class, dir(x)
returns an alphabetized
list of the names containing the instance attributes and methods and attributes
defined by its class.
How can my code discover the name of an object?¶
Generally speaking, it can’t, because objects don’t really have names.
Essentially, assignment always binds a name to a value; the same is true of
def
and class
statements, but in that case the value is a
callable. Consider the following code:
>>> class A:
... pass
...
>>> B = A
>>> a = B()
>>> b = a
>>> print(b)
<__main__.A object at 0x16D07CC>
>>> print(a)
<__main__.A object at 0x16D07CC>
Arguably the class has a name: even though it is bound to two names and invoked
through the name B
the created instance is still reported as an instance of
class A
. However, it is impossible to say whether the instance’s name is a
or
b
, since both names are bound to the same value.
Generally speaking it should not be necessary for your code to “know the names” of particular values. Unless you are deliberately writing introspective programs, this is usually an indication that a change of approach might be beneficial.
In comp.lang.python, Fredrik Lundh once gave an excellent analogy in answer to this question:
The same way as you get the name of that cat you found on your porch: the cat (object) itself cannot tell you its name, and it doesn’t really care – so the only way to find out what it’s called is to ask all your neighbours (namespaces) if it’s their cat (object)…
….and don’t be surprised if you’ll find that it’s known by many names, or no name at all!
What’s up with the comma operator’s precedence?¶
Comma is not an operator in Python. Consider this session:
>>> "a" in "b", "a"
(False, 'a')
Since the comma is not an operator, but a separator between expressions the above is evaluated as if you had entered:
("a" in "b"), "a"
not:
"a" in ("b", "a")
The same is true of the various assignment operators (=
, +=
etc). They
are not truly operators but syntactic delimiters in assignment statements.
Is there an equivalent of C’s “?:” ternary operator?¶
Yes, there is. The syntax is as follows:
[on_true] if [expression] else [on_false]
x, y = 50, 25
small = x if x < y else y
Before this syntax was introduced in Python 2.5, a common idiom was to use logical operators:
[expression] and [on_true] or [on_false]
However, this idiom is unsafe, as it can give wrong results when on_true
has a false boolean value. Therefore, it is always better to use
the ... if ... else ...
form.
Is it possible to write obfuscated one-liners in Python?¶
Yes. Usually this is done by nesting lambda
within
lambda
. See the following three examples, slightly adapted from Ulf Bartelt:
from functools import reduce
# Primes < 1000
print(list(filter(None,map(lambda y:y*reduce(lambda x,y:x*y!=0,
map(lambda x,y=y:y%x,range(2,int(pow(y,0.5)+1))),1),range(2,1000)))))
# First 10 Fibonacci numbers
print(list(map(lambda x,f=lambda x,f:(f(x-1,f)+f(x-2,f)) if x>1 else 1:
f(x,f), range(10))))
# Mandelbrot set
print((lambda Ru,Ro,Iu,Io,IM,Sx,Sy:reduce(lambda x,y:x+'\n'+y,map(lambda y,
Iu=Iu,Io=Io,Ru=Ru,Ro=Ro,Sy=Sy,L=lambda yc,Iu=Iu,Io=Io,Ru=Ru,Ro=Ro,i=IM,
Sx=Sx,Sy=Sy:reduce(lambda x,y:x+y,map(lambda x,xc=Ru,yc=yc,Ru=Ru,Ro=Ro,
i=i,Sx=Sx,F=lambda xc,yc,x,y,k,f=lambda xc,yc,x,y,k,f:(k<=0)or (x*x+y*y
>=4.0) or 1+f(xc,yc,x*x-y*y+xc,2.0*x*y+yc,k-1,f):f(xc,yc,x,y,k,f):chr(
64+F(Ru+x*(Ro-Ru)/Sx,yc,0,0,i)),range(Sx))):L(Iu+y*(Io-Iu)/Sy),range(Sy
))))(-2.1, 0.7, -1.2, 1.2, 30, 80, 24))
# \___ ___/ \___ ___/ | | |__ lines on screen
# V V | |______ columns on screen
# | | |__________ maximum of "iterations"
# | |_________________ range on y axis
# |____________________________ range on x axis
Don’t try this at home, kids!
What does the slash(/) in the parameter list of a function mean?¶
A slash in the argument list of a function denotes that the parameters prior to
it are positional-only. Positional-only parameters are the ones without an
externally usable name. Upon calling a function that accepts positional-only
parameters, arguments are mapped to parameters based solely on their position.
For example, divmod()
is a function that accepts positional-only
parameters. Its documentation looks like this:
>>> help(divmod)
Help on built-in function divmod in module builtins:
divmod(x, y, /)
Return the tuple (x//y, x%y). Invariant: div*y + mod == x.
The slash at the end of the parameter list means that both parameters are
positional-only. Thus, calling divmod()
with keyword arguments would lead
to an error:
>>> divmod(x=3, y=4)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: divmod() takes no keyword arguments
Numbers and strings¶
How do I specify hexadecimal and octal integers?¶
To specify an octal digit, precede the octal value with a zero, and then a lower or uppercase “o”. For example, to set the variable “a” to the octal value “10” (8 in decimal), type:
>>> a = 0o10
>>> a
8
Hexadecimal is just as easy. Simply precede the hexadecimal number with a zero, and then a lower or uppercase “x”. Hexadecimal digits can be specified in lower or uppercase. For example, in the Python interpreter:
>>> a = 0xa5
>>> a
165
>>> b = 0XB2
>>> b
178
Why does -22 // 10 return -3?¶
It’s primarily driven by the desire that i % j
have the same sign as j
.
If you want that, and also want:
i == (i // j) * j + (i % j)
then integer division has to return the floor. C also requires that identity to
hold, and then compilers that truncate i // j
need to make i % j
have
the same sign as i
.
There are few real use cases for i % j
when j
is negative. When j
is positive, there are many, and in virtually all of them it’s more useful for
i % j
to be >= 0
. If the clock says 10 now, what did it say 200 hours
ago? -190 % 12 == 2
is useful; -190 % 12 == -10
is a bug waiting to
bite.
How do I get int literal attribute instead of SyntaxError?¶
Trying to lookup an int
literal attribute in the normal manner gives
a SyntaxError
because the period is seen as a decimal point:
>>> 1.__class__
File "<stdin>", line 1
1.__class__
^
SyntaxError: invalid decimal literal
The solution is to separate the literal from the period with either a space or parentheses.
>>> 1 .__class__
<class 'int'>
>>> (1).__class__
<class 'int'>
How do I convert a string to a number?¶
For integers, use the built-in int()
type constructor, e.g. int('144')
== 144
. Similarly, float()
converts to a floating-point number,
e.g. float('144') == 144.0
.
By default, these interpret the number as decimal, so that int('0144') ==
144
holds true, and int('0x144')
raises ValueError
. int(string,
base)
takes the base to convert from as a second optional argument, so int(
'0x144', 16) == 324
. If the base is specified as 0, the number is interpreted
using Python’s rules: a leading ‘0o’ indicates octal, and ‘0x’ indicates a hex
number.
Do not use the built-in function eval()
if all you need is to convert
strings to numbers. eval()
will be significantly slower and it presents a
security risk: someone could pass you a Python expression that might have
unwanted side effects. For example, someone could pass
__import__('os').system("rm -rf $HOME")
which would erase your home
directory.
eval()
also has the effect of interpreting numbers as Python expressions,
so that e.g. eval('09')
gives a syntax error because Python does not allow
leading ‘0’ in a decimal number (except ‘0’).
How do I convert a number to a string?¶
To convert, e.g., the number 144
to the string '144'
, use the built-in type
constructor str()
. If you want a hexadecimal or octal representation, use
the built-in functions hex()
or oct()
. For fancy formatting, see
the f-strings and Format String Syntax sections,
e.g. "{:04d}".format(144)
yields
'0144'
and "{:.3f}".format(1.0/3.0)
yields '0.333'
.
How do I modify a string in place?¶
You can’t, because strings are immutable. In most situations, you should
simply construct a new string from the various parts you want to assemble
it from. However, if you need an object with the ability to modify in-place
unicode data, try using an io.StringIO
object or the array
module:
>>> import io
>>> s = "Hello, world"
>>> sio = io.StringIO(s)
>>> sio.getvalue()
'Hello, world'
>>> sio.seek(7)
7
>>> sio.write("there!")
6
>>> sio.getvalue()
'Hello, there!'
>>> import array
>>> a = array.array('w', s)
>>> print(a)
array('w', 'Hello, world')
>>> a[0] = 'y'
>>> print(a)
array('w', 'yello, world')
>>> a.tounicode()
'yello, world'
How do I use strings to call functions/methods?¶
There are various techniques.
The best is to use a dictionary that maps strings to functions. The primary advantage of this technique is that the strings do not need to match the names of the functions. This is also the primary technique used to emulate a case construct:
def a(): pass def b(): pass dispatch = {'go': a, 'stop': b} # Note lack of parens for funcs dispatch[get_input()]() # Note trailing parens to call function
Use the built-in function
getattr()
:import foo getattr(foo, 'bar')()
Note that
getattr()
works on any object, including classes, class instances, modules, and so on.This is used in several places in the standard library, like this:
class Foo: def do_foo(self): ... def do_bar(self): ... f = getattr(foo_instance, 'do_' + opname) f()
Use
locals()
to resolve the function name:def myFunc(): print("hello") fname = "myFunc" f = locals()[fname] f()
Is there an equivalent to Perl’s chomp()
for removing trailing newlines from strings?¶
You can use S.rstrip("\r\n")
to remove all occurrences of any line
terminator from the end of the string S
without removing other trailing
whitespace. If the string S
represents more than one line, with several
empty lines at the end, the line terminators for all the blank lines will
be removed:
>>> lines = ("line 1 \r\n"
... "\r\n"
... "\r\n")
>>> lines.rstrip("\n\r")
'line 1 '
Since this is typically only desired when reading text one line at a time, using
S.rstrip()
this way works well.
Is there a scanf()
or sscanf()
equivalent?¶
Not as such.
For simple input parsing, the easiest approach is usually to split the line into
whitespace-delimited words using the split()
method of string objects
and then convert decimal strings to numeric values using int()
or
float()
. split()
supports an optional “sep” parameter which is useful
if the line uses something other than whitespace as a separator.
For more complicated input parsing, regular expressions are more powerful
than C’s sscanf
and better suited for the task.
What does UnicodeDecodeError
or UnicodeEncodeError
error mean?¶
See the Unicode HOWTO.
Can I end a raw string with an odd number of backslashes?¶
A raw string ending with an odd number of backslashes will escape the string’s quote:
>>> r'C:\this\will\not\work\'
File "<stdin>", line 1
r'C:\this\will\not\work\'
^
SyntaxError: unterminated string literal (detected at line 1)
There are several workarounds for this. One is to use regular strings and double the backslashes:
>>> 'C:\\this\\will\\work\\'
'C:\\this\\will\\work\\'
Another is to concatenate a regular string containing an escaped backslash to the raw string:
>>> r'C:\this\will\work' '\\'
'C:\\this\\will\\work\\'
It is also possible to use os.path.join()
to append a backslash on Windows:
>>> os.path.join(r'C:\this\will\work', '')
'C:\\this\\will\\work\\'
Note that while a backslash will “escape” a quote for the purposes of determining where the raw string ends, no escaping occurs when interpreting the value of the raw string. That is, the backslash remains present in the value of the raw string:
>>> r'backslash\'preserved'
"backslash\\'preserved"
Also see the specification in the language reference.
Performance¶
My program is too slow. How do I speed it up?¶
That’s a tough one, in general. First, here are a list of things to remember before diving further:
Performance characteristics vary across Python implementations. This FAQ focuses on CPython.
Behaviour can vary across operating systems, especially when talking about I/O or multi-threading.
You should always find the hot spots in your program before attempting to optimize any code (see the
profile
module).Writing benchmark scripts will allow you to iterate quickly when searching for improvements (see the
timeit
module).It is highly recommended to have good code coverage (through unit testing or any other technique) before potentially introducing regressions hidden in sophisticated optimizations.
That being said, there are many tricks to speed up Python code. Here are some general principles which go a long way towards reaching acceptable performance levels:
Making your algorithms faster (or changing to faster ones) can yield much larger benefits than trying to sprinkle micro-optimization tricks all over your code.
Use the right data structures. Study documentation for the Built-in Types and the
collections
module.When the standard library provides a primitive for doing something, it is likely (although not guaranteed) to be faster than any alternative you may come up with. This is doubly true for primitives written in C, such as builtins and some extension types. For example, be sure to use either the
list.sort()
built-in method or the relatedsorted()
function to do sorting (and see the Sorting Techniques for examples of moderately advanced usage).Abstractions tend to create indirections and force the interpreter to work more. If the levels of indirection outweigh the amount of useful work done, your program will be slower. You should avoid excessive abstraction, especially under the form of tiny functions or methods (which are also often detrimental to readability).
If you have reached the limit of what pure Python can allow, there are tools to take you further away. For example, Cython can compile a slightly modified version of Python code into a C extension, and can be used on many different platforms. Cython can take advantage of compilation (and optional type annotations) to make your code significantly faster than when interpreted. If you are confident in your C programming skills, you can also write a C extension module yourself.
See also
The wiki page devoted to performance tips.
What is the most efficient way to concatenate many strings together?¶
str
and bytes
objects are immutable, therefore concatenating
many strings together is inefficient as each concatenation creates a new
object. In the general case, the total runtime cost is quadratic in the
total string length.
To accumulate many str
objects, the recommended idiom is to place
them into a list and call str.join()
at the end:
chunks = []
for s in my_strings:
chunks.append(s)
result = ''.join(chunks)
(another reasonably efficient idiom is to use io.StringIO
)
To accumulate many bytes
objects, the recommended idiom is to extend
a bytearray
object using in-place concatenation (the +=
operator):
result = bytearray()
for b in my_bytes_objects:
result += b
Sequences (Tuples/Lists)¶
How do I convert between tuples and lists?¶
The type constructor tuple(seq)
converts any sequence (actually, any
iterable) into a tuple with the same items in the same order.
For example, tuple([1, 2, 3])
yields (1, 2, 3)
and tuple('abc')
yields ('a', 'b', 'c')
. If the argument is a tuple, it does not make a copy
but returns the same object, so it is cheap to call tuple()
when you
aren’t sure that an object is already a tuple.
The type constructor list(seq)
converts any sequence or iterable into a list
with the same items in the same order. For example, list((1, 2, 3))
yields
[1, 2, 3]
and list('abc')
yields ['a', 'b', 'c']
. If the argument
is a list, it makes a copy just like seq[:]
would.
What’s a negative index?¶
Python sequences are indexed with positive numbers and negative numbers. For
positive numbers 0 is the first index 1 is the second index and so forth. For
negative indices -1 is the last index and -2 is the penultimate (next to last)
index and so forth. Think of seq[-n]
as the same as seq[len(seq)-n]
.
Using negative indices can be very convenient. For example S[:-1]
is all of
the string except for its last character, which is useful for removing the
trailing newline from a string.
How do I iterate over a sequence in reverse order?¶
Use the reversed()
built-in function:
for x in reversed(sequence):
... # do something with x ...
This won’t touch your original sequence, but build a new copy with reversed order to iterate over.
How do you remove duplicates from a list?¶
See the Python Cookbook for a long discussion of many ways to do this:
If you don’t mind reordering the list, sort it and then scan from the end of the list, deleting duplicates as you go:
if mylist:
mylist.sort()
last = mylist[-1]
for i in range(len(mylist)-2, -1, -1):
if last == mylist[i]:
del mylist[i]
else:
last = mylist[i]
If all elements of the list may be used as set keys (i.e. they are all hashable) this is often faster
mylist = list(set(mylist))
This converts the list into a set, thereby removing duplicates, and then back into a list.
How do you remove multiple items from a list?¶
As with removing duplicates, explicitly iterating in reverse with a delete condition is one possibility. However, it is easier and faster to use slice replacement with an implicit or explicit forward iteration. Here are three variations:
mylist[:] = filter(keep_function, mylist)
mylist[:] = (x for x in mylist if keep_condition)
mylist[:] = [x for x in mylist if keep_condition]
The list comprehension may be fastest.
How do you make an array in Python?¶
Use a list:
["this", 1, "is", "an", "array"]
Lists are equivalent to C or Pascal arrays in their time complexity; the primary difference is that a Python list can contain objects of many different types.
The array
module also provides methods for creating arrays of fixed types
with compact representations, but they are slower to index than lists. Also
note that NumPy
and other third party packages define array-like structures with
various characteristics as well.
To get Lisp-style linked lists, you can emulate cons cells using tuples:
lisp_list = ("like", ("this", ("example", None) ) )
If mutability is desired, you could use lists instead of tuples. Here the
analogue of a Lisp car is lisp_list[0]
and the analogue of cdr is
lisp_list[1]
. Only do this if you’re sure you really need to, because it’s
usually a lot slower than using Python lists.
How do I create a multidimensional list?¶
You probably tried to make a multidimensional array like this:
>>> A = [[None] * 2] * 3
This looks correct if you print it:
>>> A
[[None, None], [None, None], [None, None]]
But when you assign a value, it shows up in multiple places:
>>> A[0][0] = 5
>>> A
[[5, None], [5, None], [5, None]]
The reason is that replicating a list with *
doesn’t create copies, it only
creates references to the existing objects. The *3
creates a list
containing 3 references to the same list of length two. Changes to one row will
show in all rows, which is almost certainly not what you want.
The suggested approach is to create a list of the desired length first and then fill in each element with a newly created list:
A = [None] * 3
for i in range(3):
A[i] = [None] * 2
This generates a list containing 3 different lists of length two. You can also use a list comprehension:
w, h = 2, 3
A = [[None] * w for i in range(h)]
Or, you can use an extension that provides a matrix datatype; NumPy is the best known.
How do I apply a method or function to a sequence of objects?¶
To call a method or function and accumulate the return values is a list, a list comprehension is an elegant solution:
result = [obj.method() for obj in mylist]
result = [function(obj) for obj in mylist]
To just run the method or function without saving the return values,
a plain for
loop will suffice:
for obj in mylist:
obj.method()
for obj in mylist:
function(obj)
Why does a_tuple[i] += [‘item’] raise an exception when the addition works?¶
This is because of a combination of the fact that augmented assignment operators are assignment operators, and the difference between mutable and immutable objects in Python.
This discussion applies in general when augmented assignment operators are
applied to elements of a tuple that point to mutable objects, but we’ll use
a list
and +=
as our exemplar.
If you wrote:
>>> a_tuple = (1, 2)
>>> a_tuple[0] += 1
Traceback (most recent call last):
...
TypeError: 'tuple' object does not support item assignment
The reason for the exception should be immediately clear: 1
is added to the
object a_tuple[0]
points to (1
), producing the result object, 2
,
but when we attempt to assign the result of the computation, 2
, to element
0
of the tuple, we get an error because we can’t change what an element of
a tuple points to.
Under the covers, what this augmented assignment statement is doing is approximately this:
>>> result = a_tuple[0] + 1
>>> a_tuple[0] = result
Traceback (most recent call last):
...
TypeError: 'tuple' object does not support item assignment
It is the assignment part of the operation that produces the error, since a tuple is immutable.
When you write something like:
>>> a_tuple = (['foo'], 'bar')
>>> a_tuple[0] += ['item']
Traceback (most recent call last):
...
TypeError: 'tuple' object does not support item assignment
The exception is a bit more surprising, and even more surprising is the fact that even though there was an error, the append worked:
>>> a_tuple[0]
['foo', 'item']
To see why this happens, you need to know that (a) if an object implements an
__iadd__()
magic method, it gets called when the +=
augmented
assignment
is executed, and its return value is what gets used in the assignment statement;
and (b) for lists, __iadd__()
is equivalent to calling
extend()
on the list and returning the list.
That’s why we say that for lists, +=
is a “shorthand” for list.extend()
:
>>> a_list = []
>>> a_list += [1]
>>> a_list
[1]
This is equivalent to:
>>> result = a_list.__iadd__([1])
>>> a_list = result
The object pointed to by a_list has been mutated, and the pointer to the
mutated object is assigned back to a_list
. The end result of the
assignment is a no-op, since it is a pointer to the same object that a_list
was previously pointing to, but the assignment still happens.
Thus, in our tuple example what is happening is equivalent to:
>>> result = a_tuple[0].__iadd__(['item'])
>>> a_tuple[0] = result
Traceback (most recent call last):
...
TypeError: 'tuple' object does not support item assignment
The __iadd__()
succeeds, and thus the list is extended, but even though
result
points to the same object that a_tuple[0]
already points to,
that final assignment still results in an error, because tuples are immutable.
I want to do a complicated sort: can you do a Schwartzian Transform in Python?¶
The technique, attributed to Randal Schwartz of the Perl community, sorts the
elements of a list by a metric which maps each element to its “sort value”. In
Python, use the key
argument for the list.sort()
method:
Isorted = L[:]
Isorted.sort(key=lambda s: int(s[10:15]))
How can I sort one list by values from another list?¶
Merge them into an iterator of tuples, sort the resulting list, and then pick out the element you want.
>>> list1 = ["what", "I'm", "sorting", "by"]
>>> list2 = ["something", "else", "to", "sort"]
>>> pairs = zip(list1, list2)
>>> pairs = sorted(pairs)
>>> pairs
[("I'm", 'else'), ('by', 'sort'), ('sorting', 'to'), ('what', 'something')]
>>> result = [x[1] for x in pairs]
>>> result
['else', 'sort', 'to', 'something']
Objects¶
What is a class?¶
A class is the particular object type created by executing a class statement. Class objects are used as templates to create instance objects, which embody both the data (attributes) and code (methods) specific to a datatype.
A class can be based on one or more other classes, called its base class(es). It
then inherits the attributes and methods of its base classes. This allows an
object model to be successively refined by inheritance. You might have a
generic Mailbox
class that provides basic accessor methods for a mailbox,
and subclasses such as MboxMailbox
, MaildirMailbox
, OutlookMailbox
that handle various specific mailbox formats.
What is a method?¶
A method is a function on some object x
that you normally call as
x.name(arguments...)
. Methods are defined as functions inside the class
definition:
class C:
def meth(self, arg):
return arg * 2 + self.attribute
What is self?¶
Self is merely a conventional name for the first argument of a method. A method
defined as meth(self, a, b, c)
should be called as x.meth(a, b, c)
for
some instance x
of the class in which the definition occurs; the called
method will think it is called as meth(x, a, b, c)
.
See also Why must ‘self’ be used explicitly in method definitions and calls?.
How do I check if an object is an instance of a given class or of a subclass of it?¶
Use the built-in function isinstance(obj, cls)
. You can
check if an object
is an instance of any of a number of classes by providing a tuple instead of a
single class, e.g. isinstance(obj, (class1, class2, ...))
, and can also
check whether an object is one of Python’s built-in types, e.g.
isinstance(obj, str)
or isinstance(obj, (int, float, complex))
.
Note that isinstance()
also checks for virtual inheritance from an
abstract base class. So, the test will return True
for a
registered class even if hasn’t directly or indirectly inherited from it. To
test for “true inheritance”, scan the MRO of the class:
from collections.abc import Mapping
class P:
pass
class C(P):
pass
Mapping.register(P)
>>> c = C()
>>> isinstance(c, C) # direct
True
>>> isinstance(c, P) # indirect
True
>>> isinstance(c, Mapping) # virtual
True
# Actual inheritance chain
>>> type(c).__mro__
(<class 'C'>, <class 'P'>, <class 'object'>)
# Test for "true inheritance"
>>> Mapping in type(c).__mro__
False
Note that most programs do not use isinstance()
on user-defined classes
very often. If you are developing the classes yourself, a more proper
object-oriented style is to define methods on the classes that encapsulate a
particular behaviour, instead of checking the object’s class and doing a
different thing based on what class it is. For example, if you have a function
that does something:
def search(obj):
if isinstance(obj, Mailbox):
... # code to search a mailbox
elif isinstance(obj, Document):
... # code to search a document
elif ...
A better approach is to define a search()
method on all the classes and just
call it:
class Mailbox:
def search(self):
... # code to search a mailbox
class Document:
def search(self):
... # code to search a document
obj.search()
What is delegation?¶
Delegation is an object oriented technique (also called a design pattern).
Let’s say you have an object x
and want to change the behaviour of just one
of its methods. You can create a new class that provides a new implementation
of the method you’re interested in changing and delegates all other methods to
the corresponding method of x
.
Python programmers can easily implement delegation. For example, the following class implements a class that behaves like a file but converts all written data to uppercase:
class UpperOut:
def __init__(self, outfile):
self._outfile = outfile
def write(self, s):
self._outfile.write(s.upper())
def __getattr__(self, name):
return getattr(self._outfile, name)
Here the UpperOut
class redefines the write()
method to convert the
argument string to uppercase before calling the underlying
self._outfile.write()
method. All other methods are delegated to the
underlying self._outfile
object. The delegation is accomplished via the
__getattr__()
method; consult the language reference
for more information about controlling attribute access.
Note that for more general cases delegation can get trickier. When attributes
must be set as well as retrieved, the class must define a __setattr__()
method too, and it must do so carefully. The basic implementation of
__setattr__()
is roughly equivalent to the following:
class X:
...
def __setattr__(self, name, value):
self.__dict__[name] = value
...
Many __setattr__()
implementations call object.__setattr__()
to set
an attribute on self without causing infinite recursion:
class X:
def __setattr__(self, name, value):
# Custom logic here...
object.__setattr__(self, name, value)
Alternatively, it is possible to set attributes by inserting
entries into self.__dict__
directly.
How do I call a method defined in a base class from a derived class that extends it?¶
Use the built-in super()
function:
class Derived(Base):
def meth(self):
super().meth() # calls Base.meth
In the example, super()
will automatically determine the instance from
which it was called (the self
value), look up the method resolution
order (MRO) with type(self).__mro__
, and return the next in line after
Derived
in the MRO: Base
.
How can I organize my code to make it easier to change the base class?¶
You could assign the base class to an alias and derive from the alias. Then all you have to change is the value assigned to the alias. Incidentally, this trick is also handy if you want to decide dynamically (e.g. depending on availability of resources) which base class to use. Example:
class Base:
...
BaseAlias = Base
class Derived(BaseAlias):
...
How do I create static class data and static class methods?¶
Both static data and static methods (in the sense of C++ or Java) are supported in Python.
For static data, simply define a class attribute. To assign a new value to the attribute, you have to explicitly use the class name in the assignment:
class C:
count = 0 # number of times C.__init__ called
def __init__(self):
C.count = C.count + 1
def getcount(self):
return C.count # or return self.count
c.count
also refers to C.count
for any c
such that isinstance(c,
C)
holds, unless overridden by c
itself or by some class on the base-class
search path from c.__class__
back to C
.
Caution: within a method of C, an assignment like self.count = 42
creates a
new and unrelated instance named “count” in self
’s own dict. Rebinding of a
class-static data name must always specify the class whether inside a method or
not:
C.count = 314
Static methods are possible:
class C:
@staticmethod
def static(arg1, arg2, arg3):
# No 'self' parameter!
...
However, a far more straightforward way to get the effect of a static method is via a simple module-level function:
def getcount():
return C.count
If your code is structured so as to define one class (or tightly related class hierarchy) per module, this supplies the desired encapsulation.
How can I overload constructors (or methods) in Python?¶
This answer actually applies to all methods, but the question usually comes up first in the context of constructors.
In C++ you’d write
class C {
C() { cout << "No arguments\n"; }
C(int i) { cout << "Argument is " << i << "\n"; }
}
In Python you have to write a single constructor that catches all cases using default arguments. For example:
class C:
def __init__(self, i=None):
if i is None:
print("No arguments")
else:
print("Argument is", i)
This is not entirely equivalent, but close enough in practice.
You could also try a variable-length argument list, e.g.
def __init__(self, *args):
...
The same approach works for all method definitions.
I try to use __spam and I get an error about _SomeClassName__spam.¶
Variable names with double leading underscores are “mangled” to provide a simple
but effective way to define class private variables. Any identifier of the form
__spam
(at least two leading underscores, at most one trailing underscore)
is textually replaced with _classname__spam
, where classname
is the
current class name with any leading underscores stripped.
The identifier can be used unchanged within the class, but to access it outside the class, the mangled name must be used:
class A:
def __one(self):
return 1
def two(self):
return 2 * self.__one()
class B(A):
def three(self):
return 3 * self._A__one()
four = 4 * A()._A__one()
In particular, this does not guarantee privacy since an outside user can still deliberately access the private attribute; many Python programmers never bother to use private variable names at all.
See also
The private name mangling specifications for details and special cases.
My class defines __del__ but it is not called when I delete the object.¶
There are several possible reasons for this.
The del
statement does not necessarily call __del__()
– it simply
decrements the object’s reference count, and if this reaches zero
__del__()
is called.
If your data structures contain circular links (e.g. a tree where each child has
a parent reference and each parent has a list of children) the reference counts
will never go back to zero. Once in a while Python runs an algorithm to detect
such cycles, but the garbage collector might run some time after the last
reference to your data structure vanishes, so your __del__()
method may be
called at an inconvenient and random time. This is inconvenient if you’re trying
to reproduce a problem. Worse, the order in which object’s __del__()
methods are executed is arbitrary. You can run gc.collect()
to force a
collection, but there are pathological cases where objects will never be
collected.
Despite the cycle collector, it’s still a good idea to define an explicit
close()
method on objects to be called whenever you’re done with them. The
close()
method can then remove attributes that refer to subobjects. Don’t
call __del__()
directly – __del__()
should call close()
and
close()
should make sure that it can be called more than once for the same
object.
Another way to avoid cyclical references is to use the weakref
module,
which allows you to point to objects without incrementing their reference count.
Tree data structures, for instance, should use weak references for their parent
and sibling references (if they need them!).
Finally, if your __del__()
method raises an exception, a warning message
is printed to sys.stderr
.
How do I get a list of all instances of a given class?¶
Python does not keep track of all instances of a class (or of a built-in type). You can program the class’s constructor to keep track of all instances by keeping a list of weak references to each instance.
Why does the result of id()
appear to be not unique?¶
The id()
builtin returns an integer that is guaranteed to be unique during
the lifetime of the object. Since in CPython, this is the object’s memory
address, it happens frequently that after an object is deleted from memory, the
next freshly created object is allocated at the same position in memory. This
is illustrated by this example:
>>> id(1000)
13901272
>>> id(2000)
13901272
The two ids belong to different integer objects that are created before, and
deleted immediately after execution of the id()
call. To be sure that
objects whose id you want to examine are still alive, create another reference
to the object:
>>> a = 1000; b = 2000
>>> id(a)
13901272
>>> id(b)
13891296
When can I rely on identity tests with the is operator?¶
The is
operator tests for object identity. The test a is b
is
equivalent to id(a) == id(b)
.
The most important property of an identity test is that an object is always
identical to itself, a is a
always returns True
. Identity tests are
usually faster than equality tests. And unlike equality tests, identity tests
are guaranteed to return a boolean True
or False
.
However, identity tests can only be substituted for equality tests when object identity is assured. Generally, there are three circumstances where identity is guaranteed:
Assignments create new names but do not change object identity. After the assignment
new = old
, it is guaranteed thatnew is old
.Putting an object in a container that stores object references does not change object identity. After the list assignment
s[0] = x
, it is guaranteed thats[0] is x
.If an object is a singleton, it means that only one instance of that object can exist. After the assignments
a = None
andb = None
, it is guaranteed thata is b
becauseNone
is a singleton.
In most other circumstances, identity tests are inadvisable and equality tests
are preferred. In particular, identity tests should not be used to check
constants such as int
and str
which aren’t guaranteed to be
singletons:
>>> a = 1000
>>> b = 500
>>> c = b + 500
>>> a is c
False
>>> a = 'Python'
>>> b = 'Py'
>>> c = b + 'thon'
>>> a is c
False
Likewise, new instances of mutable containers are never identical:
>>> a = []
>>> b = []
>>> a is b
False
In the standard library code, you will see several common patterns for correctly using identity tests:
As recommended by PEP 8, an identity test is the preferred way to check for
None
. This reads like plain English in code and avoids confusion with other objects that may have boolean values that evaluate to false.Detecting optional arguments can be tricky when
None
is a valid input value. In those situations, you can create a singleton sentinel object guaranteed to be distinct from other objects. For example, here is how to implement a method that behaves likedict.pop()
:_sentinel = object() def pop(self, key, default=_sentinel): if key in self: value = self[key] del self[key] return value if default is _sentinel: raise KeyError(key) return default
Container implementations sometimes need to augment equality tests with identity tests. This prevents the code from being confused by objects such as
float('NaN')
that are not equal to themselves.
For example, here is the implementation of
collections.abc.Sequence.__contains__()
:
def __contains__(self, value):
for v in self:
if v is value or v == value:
return True
return False
How can a subclass control what data is stored in an immutable instance?¶
When subclassing an immutable type, override the __new__()
method
instead of the __init__()
method. The latter only runs after an
instance is created, which is too late to alter data in an immutable
instance.
All of these immutable classes have a different signature than their parent class:
from datetime import date
class FirstOfMonthDate(date):
"Always choose the first day of the month"
def __new__(cls, year, month, day):
return super().__new__(cls, year, month, 1)
class NamedInt(int):
"Allow text names for some numbers"
xlat = {'zero': 0, 'one': 1, 'ten': 10}
def __new__(cls, value):
value = cls.xlat.get(value, value)
return super().__new__(cls, value)
class TitleStr(str):
"Convert str to name suitable for a URL path"
def __new__(cls, s):
s = s.lower().replace(' ', '-')
s = ''.join([c for c in s if c.isalnum() or c == '-'])
return super().__new__(cls, s)
The classes can be used like this:
>>> FirstOfMonthDate(2012, 2, 14)
FirstOfMonthDate(2012, 2, 1)
>>> NamedInt('ten')
10
>>> NamedInt(20)
20
>>> TitleStr('Blog: Why Python Rocks')
'blog-why-python-rocks'
How do I cache method calls?¶
The two principal tools for caching methods are
functools.cached_property()
and functools.lru_cache()
. The
former stores results at the instance level and the latter at the class
level.
The cached_property approach only works with methods that do not take any arguments. It does not create a reference to the instance. The cached method result will be kept only as long as the instance is alive.
The advantage is that when an instance is no longer used, the cached method result will be released right away. The disadvantage is that if instances accumulate, so too will the accumulated method results. They can grow without bound.
The lru_cache approach works with methods that have hashable arguments. It creates a reference to the instance unless special efforts are made to pass in weak references.
The advantage of the least recently used algorithm is that the cache is bounded by the specified maxsize. The disadvantage is that instances are kept alive until they age out of the cache or until the cache is cleared.
This example shows the various techniques:
class Weather:
"Lookup weather information on a government website"
def __init__(self, station_id):
self._station_id = station_id
# The _station_id is private and immutable
def current_temperature(self):
"Latest hourly observation"
# Do not cache this because old results
# can be out of date.
@cached_property
def location(self):
"Return the longitude/latitude coordinates of the station"
# Result only depends on the station_id
@lru_cache(maxsize=20)
def historic_rainfall(self, date, units='mm'):
"Rainfall on a given date"
# Depends on the station_id, date, and units.
The above example assumes that the station_id never changes. If the relevant instance attributes are mutable, the cached_property approach can’t be made to work because it cannot detect changes to the attributes.
To make the lru_cache approach work when the station_id is mutable,
the class needs to define the __eq__()
and __hash__()
methods so that the cache can detect relevant attribute updates:
class Weather:
"Example with a mutable station identifier"
def __init__(self, station_id):
self.station_id = station_id
def change_station(self, station_id):
self.station_id = station_id
def __eq__(self, other):
return self.station_id == other.station_id
def __hash__(self):
return hash(self.station_id)
@lru_cache(maxsize=20)
def historic_rainfall(self, date, units='cm'):
'Rainfall on a given date'
# Depends on the station_id, date, and units.
Modules¶
How do I create a .pyc file?¶
When a module is imported for the first time (or when the source file has
changed since the current compiled file was created) a .pyc
file containing
the compiled code should be created in a __pycache__
subdirectory of the
directory containing the .py
file. The .pyc
file will have a
filename that starts with the same name as the .py
file, and ends with
.pyc
, with a middle component that depends on the particular python
binary that created it. (See PEP 3147 for details.)
One reason that a .pyc
file may not be created is a permissions problem
with the directory containing the source file, meaning that the __pycache__
subdirectory cannot be created. This can happen, for example, if you develop as
one user but run as another, such as if you are testing with a web server.
Unless the PYTHONDONTWRITEBYTECODE
environment variable is set,
creation of a .pyc file is automatic if you’re importing a module and Python
has the ability (permissions, free space, etc…) to create a __pycache__
subdirectory and write the compiled module to that subdirectory.
Running Python on a top level script is not considered an import and no
.pyc
will be created. For example, if you have a top-level module
foo.py
that imports another module xyz.py
, when you run foo
(by
typing python foo.py
as a shell command), a .pyc
will be created for
xyz
because xyz
is imported, but no .pyc
file will be created for
foo
since foo.py
isn’t being imported.
If you need to create a .pyc
file for foo
– that is, to create a
.pyc
file for a module that is not imported – you can, using the
py_compile
and compileall
modules.
The py_compile
module can manually compile any module. One way is to use
the compile()
function in that module interactively:
>>> import py_compile
>>> py_compile.compile('foo.py')
This will write the .pyc
to a __pycache__
subdirectory in the same
location as foo.py
(or you can override that with the optional parameter
cfile
).
You can also automatically compile all files in a directory or directories using
the compileall
module. You can do it from the shell prompt by running
compileall.py
and providing the path of a directory containing Python files
to compile:
python -m compileall .
How do I find the current module name?¶
A module can find out its own module name by looking at the predefined global
variable __name__
. If this has the value '__main__'
, the program is
running as a script. Many modules that are usually used by importing them also
provide a command-line interface or a self-test, and only execute this code
after checking __name__
:
def main():
print('Running test...')
...
if __name__ == '__main__':
main()
How can I have modules that mutually import each other?¶
Suppose you have the following modules:
foo.py
:
from bar import bar_var
foo_var = 1
bar.py
:
from foo import foo_var
bar_var = 2
The problem is that the interpreter will perform the following steps:
main imports
foo
Empty globals for
foo
are createdfoo
is compiled and starts executingfoo
importsbar
Empty globals for
bar
are createdbar
is compiled and starts executingbar
importsfoo
(which is a no-op since there already is a module namedfoo
)The import mechanism tries to read
foo_var
fromfoo
globals, to setbar.foo_var = foo.foo_var
The last step fails, because Python isn’t done with interpreting foo
yet and
the global symbol dictionary for foo
is still empty.
The same thing happens when you use import foo
, and then try to access
foo.foo_var
in global code.
There are (at least) three possible workarounds for this problem.
Guido van Rossum recommends avoiding all uses of from <module> import ...
,
and placing all code inside functions. Initializations of global variables and
class variables should use constants or built-in functions only. This means
everything from an imported module is referenced as <module>.<name>
.
Jim Roskind suggests performing steps in the following order in each module:
exports (globals, functions, and classes that don’t need imported base classes)
import
statementsactive code (including globals that are initialized from imported values).
Van Rossum doesn’t like this approach much because the imports appear in a strange place, but it does work.
Matthias Urlichs recommends restructuring your code so that the recursive import is not necessary in the first place.
These solutions are not mutually exclusive.
__import__(‘x.y.z’) returns <module ‘x’>; how do I get z?¶
Consider using the convenience function import_module()
from
importlib
instead:
z = importlib.import_module('x.y.z')
When I edit an imported module and reimport it, the changes don’t show up. Why does this happen?¶
For reasons of efficiency as well as consistency, Python only reads the module file on the first time a module is imported. If it didn’t, in a program consisting of many modules where each one imports the same basic module, the basic module would be parsed and re-parsed many times. To force re-reading of a changed module, do this:
import importlib
import modname
importlib.reload(modname)
Warning: this technique is not 100% fool-proof. In particular, modules containing statements like
from modname import some_objects
will continue to work with the old version of the imported objects. If the module contains class definitions, existing class instances will not be updated to use the new class definition. This can result in the following paradoxical behaviour:
>>> import importlib
>>> import cls
>>> c = cls.C() # Create an instance of C
>>> importlib.reload(cls)
<module 'cls' from 'cls.py'>
>>> isinstance(c, cls.C) # isinstance is false?!?
False
The nature of the problem is made clear if you print out the “identity” of the class objects:
>>> hex(id(c.__class__))
'0x7352a0'
>>> hex(id(cls.C))
'0x4198d0'

File
, line
, in
:
File
, line
:
File
, line
:
:
:
:
:


Concrete Objects Layer

Concrete Objects Layer¶
The functions in this chapter are specific to certain Python object types.
Passing them an object of the wrong type is not a good idea; if you receive an
object from a Python program and you are not sure that it has the right type,
you must perform a type check first; for example, to check that an object is a
dictionary, use PyDict_Check()
. The chapter is structured like the
“family tree” of Python object types.
Warning
While the functions described in this chapter carefully check the type of the
objects which are passed in, many of them do not check for NULL
being passed
instead of a valid object. Allowing NULL
to be passed in can cause memory
access violations and immediate termination of the interpreter.
Fundamental Objects¶
This section describes Python type objects and the singleton object None
.
Numeric Objects¶
Sequence Objects¶
Generic operations on sequence objects were discussed in the previous chapter; this section deals with the specific kinds of sequence objects that are intrinsic to the Python language.
Container Objects¶
Function Objects¶
Other Objects¶
- File Objects
- Module Objects
- Module definitions
- Creating extension modules dynamically
- Support functions
- Iterator Objects
- Descriptor Objects
- Slice Objects
- MemoryView objects
- Pickle buffer objects
- Weak Reference Objects
- Capsules
- Frame Objects
- Generator Objects
- Coroutine Objects
- Context Variables Objects
- Objects for Type Hinting


What’s New in Python 2.1

What’s New in Python 2.1¶
- Author:
A.M. Kuchling
Introduction¶
This article explains the new features in Python 2.1. While there aren’t as many changes in 2.1 as there were in Python 2.0, there are still some pleasant surprises in store. 2.1 is the first release to be steered through the use of Python Enhancement Proposals, or PEPs, so most of the sizable changes have accompanying PEPs that provide more complete documentation and a design rationale for the change. This article doesn’t attempt to document the new features completely, but simply provides an overview of the new features for Python programmers. Refer to the Python 2.1 documentation, or to the specific PEP, for more details about any new feature that particularly interests you.
One recent goal of the Python development team has been to accelerate the pace of new releases, with a new release coming every 6 to 9 months. 2.1 is the first release to come out at this faster pace, with the first alpha appearing in January, 3 months after the final version of 2.0 was released.
The final release of Python 2.1 was made on April 17, 2001.
PEP 227: Nested Scopes¶
The largest change in Python 2.1 is to Python’s scoping rules. In Python 2.0, at any given time there are at most three namespaces used to look up variable names: local, module-level, and the built-in namespace. This often surprised people because it didn’t match their intuitive expectations. For example, a nested recursive function definition doesn’t work:
def f():
...
def g(value):
...
return g(value-1) + 1
...
The function g()
will always raise a NameError
exception, because
the binding of the name g
isn’t in either its local namespace or in the
module-level namespace. This isn’t much of a problem in practice (how often do
you recursively define interior functions like this?), but this also made using
the lambda
expression clumsier, and this was a problem in practice.
In code which uses lambda
you can often find local variables being
copied by passing them as the default values of arguments.
def find(self, name):
"Return list of any entries equal to 'name'"
L = filter(lambda x, name=name: x == name,
self.list_attribute)
return L
The readability of Python code written in a strongly functional style suffers greatly as a result.
The most significant change to Python 2.1 is that static scoping has been added
to the language to fix this problem. As a first effect, the name=name
default argument is now unnecessary in the above example. Put simply, when a
given variable name is not assigned a value within a function (by an assignment,
or the def
, class
, or import
statements),
references to the variable will be looked up in the local namespace of the
enclosing scope. A more detailed explanation of the rules, and a dissection of
the implementation, can be found in the PEP.
This change may cause some compatibility problems for code where the same variable name is used both at the module level and as a local variable within a function that contains further function definitions. This seems rather unlikely though, since such code would have been pretty confusing to read in the first place.
One side effect of the change is that the from module import *
and
exec
statements have been made illegal inside a function scope under
certain conditions. The Python reference manual has said all along that from
module import *
is only legal at the top level of a module, but the CPython
interpreter has never enforced this before. As part of the implementation of
nested scopes, the compiler which turns Python source into bytecodes has to
generate different code to access variables in a containing scope. from
module import *
and exec
make it impossible for the compiler to
figure this out, because they add names to the local namespace that are
unknowable at compile time. Therefore, if a function contains function
definitions or lambda
expressions with free variables, the compiler
will flag this by raising a SyntaxError
exception.
To make the preceding explanation a bit clearer, here’s an example:
x = 1
def f():
# The next line is a syntax error
exec 'x=2'
def g():
return x
Line 4 containing the exec
statement is a syntax error, since
exec
would define a new local variable named x
whose value should
be accessed by g()
.
This shouldn’t be much of a limitation, since exec
is rarely used in
most Python code (and when it is used, it’s often a sign of a poor design
anyway).
Compatibility concerns have led to nested scopes being introduced gradually; in Python 2.1, they aren’t enabled by default, but can be turned on within a module by using a future statement as described in PEP 236. (See the following section for further discussion of PEP 236.) In Python 2.2, nested scopes will become the default and there will be no way to turn them off, but users will have had all of 2.1’s lifetime to fix any breakage resulting from their introduction.
See also
- PEP 227 - Statically Nested Scopes
Written and implemented by Jeremy Hylton.
PEP 236: __future__ Directives¶
The reaction to nested scopes was widespread concern about the dangers of breaking code with the 2.1 release, and it was strong enough to make the Pythoneers take a more conservative approach. This approach consists of introducing a convention for enabling optional functionality in release N that will become compulsory in release N+1.
The syntax uses a from...import
statement using the reserved module name
__future__
. Nested scopes can be enabled by the following statement:
from __future__ import nested_scopes
While it looks like a normal import
statement, it’s not; there are
strict rules on where such a future statement can be put. They can only be at
the top of a module, and must precede any Python code or regular
import
statements. This is because such statements can affect how
the Python bytecode compiler parses code and generates bytecode, so they must
precede any statement that will result in bytecodes being produced.
See also
- PEP 236 - Back to the
__future__
Written by Tim Peters, and primarily implemented by Jeremy Hylton.
PEP 207: Rich Comparisons¶
In earlier versions, Python’s support for implementing comparisons on user-defined
classes and extension types was quite simple. Classes could implement a
__cmp__()
method that was given two instances of a class, and could only
return 0 if they were equal or +1 or -1 if they weren’t; the method couldn’t
raise an exception or return anything other than a Boolean value. Users of
Numeric Python often found this model too weak and restrictive, because in the
number-crunching programs that numeric Python is used for, it would be more
useful to be able to perform elementwise comparisons of two matrices, returning
a matrix containing the results of a given comparison for each element. If the
two matrices are of different sizes, then the compare has to be able to raise an
exception to signal the error.
In Python 2.1, rich comparisons were added in order to support this need.
Python classes can now individually overload each of the <
, <=
, >
,
>=
, ==
, and !=
operations. The new magic method names are:
Operation |
Method name |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
(The magic methods are named after the corresponding Fortran operators .LT.
.
.LE.
, &c. Numeric programmers are almost certainly quite familiar with
these names and will find them easy to remember.)
Each of these magic methods is of the form method(self, other)
, where
self
will be the object on the left-hand side of the operator, while
other
will be the object on the right-hand side. For example, the
expression A < B
will cause A.__lt__(B)
to be called.
Each of these magic methods can return anything at all: a Boolean, a matrix, a list, or any other Python object. Alternatively they can raise an exception if the comparison is impossible, inconsistent, or otherwise meaningless.
The built-in cmp(A,B)
function can use the rich comparison machinery,
and now accepts an optional argument specifying which comparison operation to
use; this is given as one of the strings "<"
, "<="
, ">"
, ">="
,
"=="
, or "!="
. If called without the optional third argument,
cmp()
will only return -1, 0, or +1 as in previous versions of Python;
otherwise it will call the appropriate method and can return any Python object.
There are also corresponding changes of interest to C programmers; there’s a new
slot tp_richcmp
in type objects and an API for performing a given rich
comparison. I won’t cover the C API here, but will refer you to PEP 207, or to
2.1’s C API documentation, for the full list of related functions.
See also
- PEP 207 - Rich Comparisons
Written by Guido van Rossum, heavily based on earlier work by David Ascher, and implemented by Guido van Rossum.
PEP 230: Warning Framework¶
Over its 10 years of existence, Python has accumulated a certain number of obsolete modules and features along the way. It’s difficult to know when a feature is safe to remove, since there’s no way of knowing how much code uses it — perhaps no programs depend on the feature, or perhaps many do. To enable removing old features in a more structured way, a warning framework was added. When the Python developers want to get rid of a feature, it will first trigger a warning in the next version of Python. The following Python version can then drop the feature, and users will have had a full release cycle to remove uses of the old feature.
Python 2.1 adds the warning framework to be used in this scheme. It adds a
warnings
module that provide functions to issue warnings, and to filter
out warnings that you don’t want to be displayed. Third-party modules can also
use this framework to deprecate old features that they no longer wish to
support.
For example, in Python 2.1 the regex
module is deprecated, so importing
it causes a warning to be printed:
>>> import regex
__main__:1: DeprecationWarning: the regex module
is deprecated; please use the re module
>>>
Warnings can be issued by calling the warnings.warn()
function:
warnings.warn("feature X no longer supported")
The first parameter is the warning message; an additional optional parameters can be used to specify a particular warning category.
Filters can be added to disable certain warnings; a regular expression pattern
can be applied to the message or to the module name in order to suppress a
warning. For example, you may have a program that uses the regex
module
and not want to spare the time to convert it to use the re
module right
now. The warning can be suppressed by calling
import warnings
warnings.filterwarnings(action = 'ignore',
message='.*regex module is deprecated',
category=DeprecationWarning,
module = '__main__')
This adds a filter that will apply only to warnings of the class
DeprecationWarning
triggered in the __main__
module, and applies
a regular expression to only match the message about the regex
module
being deprecated, and will cause such warnings to be ignored. Warnings can also
be printed only once, printed every time the offending code is executed, or
turned into exceptions that will cause the program to stop (unless the
exceptions are caught in the usual way, of course).
Functions were also added to Python’s C API for issuing warnings; refer to PEP 230 or to Python’s API documentation for the details.
See also
- PEP 5 - Guidelines for Language Evolution
Written by Paul Prescod, to specify procedures to be followed when removing old features from Python. The policy described in this PEP hasn’t been officially adopted, but the eventual policy probably won’t be too different from Prescod’s proposal.
- PEP 230 - Warning Framework
Written and implemented by Guido van Rossum.
PEP 229: New Build System¶
When compiling Python, the user had to go in and edit the Modules/Setup
file in order to enable various additional modules; the default set is
relatively small and limited to modules that compile on most Unix platforms.
This means that on Unix platforms with many more features, most notably Linux,
Python installations often don’t contain all useful modules they could.
Python 2.0 added the Distutils, a set of modules for distributing and installing extensions. In Python 2.1, the Distutils are used to compile much of the standard library of extension modules, autodetecting which ones are supported on the current machine. It’s hoped that this will make Python installations easier and more featureful.
Instead of having to edit the Modules/Setup
file in order to enable
modules, a setup.py
script in the top directory of the Python source
distribution is run at build time, and attempts to discover which modules can be
enabled by examining the modules and header files on the system. If a module is
configured in Modules/Setup
, the setup.py
script won’t attempt
to compile that module and will defer to the Modules/Setup
file’s
contents. This provides a way to specific any strange command-line flags or
libraries that are required for a specific platform.
In another far-reaching change to the build mechanism, Neil Schemenauer
restructured things so Python now uses a single makefile that isn’t recursive,
instead of makefiles in the top directory and in each of the Python/
,
Parser/
, Objects/
, and Modules/
subdirectories. This
makes building Python faster and also makes hacking the Makefiles clearer and
simpler.
See also
- PEP 229 - Using Distutils to Build Python
Written and implemented by A.M. Kuchling.
PEP 205: Weak References¶
Weak references, available through the weakref
module, are a minor but
useful new data type in the Python programmer’s toolbox.
Storing a reference to an object (say, in a dictionary or a list) has the side effect of keeping that object alive forever. There are a few specific cases where this behaviour is undesirable, object caches being the most common one, and another being circular references in data structures such as trees.
For example, consider a memoizing function that caches the results of another
function f(x)
by storing the function’s argument and its result in a
dictionary:
_cache = {}
def memoize(x):
if _cache.has_key(x):
return _cache[x]
retval = f(x)
# Cache the returned object
_cache[x] = retval
return retval
This version works for simple things such as integers, but it has a side effect;
the _cache
dictionary holds a reference to the return values, so they’ll
never be deallocated until the Python process exits and cleans up. This isn’t
very noticeable for integers, but if f()
returns an object, or a data
structure that takes up a lot of memory, this can be a problem.
Weak references provide a way to implement a cache that won’t keep objects alive
beyond their time. If an object is only accessible through weak references, the
object will be deallocated and the weak references will now indicate that the
object it referred to no longer exists. A weak reference to an object obj is
created by calling wr = weakref.ref(obj)
. The object being referred to is
returned by calling the weak reference as if it were a function: wr()
. It
will return the referenced object, or None
if the object no longer exists.
This makes it possible to write a memoize()
function whose cache doesn’t
keep objects alive, by storing weak references in the cache.
_cache = {}
def memoize(x):
if _cache.has_key(x):
obj = _cache[x]()
# If weak reference object still exists,
# return it
if obj is not None: return obj
retval = f(x)
# Cache a weak reference
_cache[x] = weakref.ref(retval)
return retval
The weakref
module also allows creating proxy objects which behave like
weak references — an object referenced only by proxy objects is deallocated –
but instead of requiring an explicit call to retrieve the object, the proxy
transparently forwards all operations to the object as long as the object still
exists. If the object is deallocated, attempting to use a proxy will cause a
weakref.ReferenceError
exception to be raised.
proxy = weakref.proxy(obj)
proxy.attr # Equivalent to obj.attr
proxy.meth() # Equivalent to obj.meth()
del obj
proxy.attr # raises weakref.ReferenceError
See also
- PEP 205 - Weak References
Written and implemented by Fred L. Drake, Jr.
PEP 232: Function Attributes¶
In Python 2.1, functions can now have arbitrary information attached to them.
People were often using docstrings to hold information about functions and
methods, because the __doc__
attribute was the only way of
attaching any
information to a function. For example, in the Zope web application server,
functions are marked as safe for public access by having a docstring, and in
John Aycock’s SPARK parsing framework, docstrings hold parts of the BNF grammar
to be parsed. This overloading is unfortunate, since docstrings are really
intended to hold a function’s documentation; for example, it means you can’t
properly document functions intended for private use in Zope.
Arbitrary attributes can now be set and retrieved on functions using the regular Python syntax:
def f(): pass
f.publish = 1
f.secure = 1
f.grammar = "A ::= B (C D)*"
The dictionary containing attributes can be accessed as the function’s
__dict__
. Unlike the __dict__
attribute of class instances, in
functions you can actually assign a new dictionary to __dict__
, though
the new value is restricted to a regular Python dictionary; you can’t be
tricky and set it to a UserDict
instance, or any other random object
that behaves like a mapping.
See also
- PEP 232 - Function Attributes
Written and implemented by Barry Warsaw.
PEP 235: Importing Modules on Case-Insensitive Platforms¶
Some operating systems have filesystems that are case-insensitive, MacOS and
Windows being the primary examples; on these systems, it’s impossible to
distinguish the filenames FILE.PY
and file.py
, even though they do store
the file’s name in its original case (they’re case-preserving, too).
In Python 2.1, the import
statement will work to simulate case-sensitivity
on case-insensitive platforms. Python will now search for the first
case-sensitive match by default, raising an ImportError
if no such file
is found, so import file
will not import a module named FILE.PY
.
Case-insensitive matching can be requested by setting the PYTHONCASEOK
environment variable before starting the Python interpreter.
PEP 217: Interactive Display Hook¶
When using the Python interpreter interactively, the output of commands is
displayed using the built-in repr()
function. In Python 2.1, the variable
sys.displayhook()
can be set to a callable object which will be called
instead of repr()
. For example, you can set it to a special
pretty-printing function:
>>> # Create a recursive data structure
... L = [1,2,3]
>>> L.append(L)
>>> L # Show Python's default output
[1, 2, 3, [...]]
>>> # Use pprint.pprint() as the display function
... import sys, pprint
>>> sys.displayhook = pprint.pprint
>>> L
[1, 2, 3, <Recursion on list with id=135143996>]
>>>
See also
- PEP 217 - Display Hook for Interactive Use
Written and implemented by Moshe Zadka.
PEP 208: New Coercion Model¶
How numeric coercion is done at the C level was significantly modified. This will only affect the authors of C extensions to Python, allowing them more flexibility in writing extension types that support numeric operations.
Extension types can now set the type flag Py_TPFLAGS_CHECKTYPES
in their
PyTypeObject
structure to indicate that they support the new coercion model.
In such extension types, the numeric slot functions can no longer assume that
they’ll be passed two arguments of the same type; instead they may be passed two
arguments of differing types, and can then perform their own internal coercion.
If the slot function is passed a type it can’t handle, it can indicate the
failure by returning a reference to the Py_NotImplemented
singleton value.
The numeric functions of the other type will then be tried, and perhaps they can
handle the operation; if the other type also returns Py_NotImplemented
, then
a TypeError
will be raised. Numeric methods written in Python can also
return Py_NotImplemented
, causing the interpreter to act as if the method
did not exist (perhaps raising a TypeError
, perhaps trying another
object’s numeric methods).
See also
- PEP 208 - Reworking the Coercion Model
Written and implemented by Neil Schemenauer, heavily based upon earlier work by Marc-André Lemburg. Read this to understand the fine points of how numeric operations will now be processed at the C level.
PEP 241: Metadata in Python Packages¶
A common complaint from Python users is that there’s no single catalog of all
the Python modules in existence. T. Middleton’s Vaults of Parnassus at
www.vex.net/parnassus/
(retired in February 2009, available in the
Internet Archive Wayback Machine)
was the largest catalog of Python modules, but
registering software at the Vaults is optional, and many people did not bother.
As a first small step toward fixing the problem, Python software packaged using
the Distutils sdist command will include a file named
PKG-INFO
containing information about the package such as its name,
version, and author (metadata, in cataloguing terminology). PEP 241 contains
the full list of fields that can be present in the PKG-INFO
file. As
people began to package their software using Python 2.1, more and more packages
will include metadata, making it possible to build automated cataloguing systems
and experiment with them. With the result experience, perhaps it’ll be possible
to design a really good catalog and then build support for it into Python 2.2.
For example, the Distutils sdist and bdist_* commands
could support an upload
option that would automatically upload your
package to a catalog server.
You can start creating packages containing PKG-INFO
even if you’re not
using Python 2.1, since a new release of the Distutils will be made for users of
earlier Python versions. Version 1.0.2 of the Distutils includes the changes
described in PEP 241, as well as various bugfixes and enhancements. It will be
available from the Distutils SIG at https://www.python.org/community/sigs/current/distutils-sig/.
New and Improved Modules¶
Ka-Ping Yee contributed two new modules:
inspect.py
, a module for getting information about live Python code, andpydoc.py
, a module for interactively converting docstrings to HTML or text. As a bonus,Tools/scripts/pydoc
, which is now automatically installed, usespydoc.py
to display documentation given a Python module, package, or class name. For example,pydoc xml.dom
displays the following:Python Library Documentation: package xml.dom in xml NAME xml.dom - W3C Document Object Model implementation for Python. FILE /usr/local/lib/python2.1/xml/dom/__init__.pyc DESCRIPTION The Python mapping of the Document Object Model is documented in the Python Library Reference in the section on the xml.dom package. This package contains the following modules: ...
pydoc
also includes a Tk-based interactive help browser.pydoc
quickly becomes addictive; try it out!Two different modules for unit testing were added to the standard library. The
doctest
module, contributed by Tim Peters, provides a testing framework based on running embedded examples in docstrings and comparing the results against the expected output. PyUnit, contributed by Steve Purcell, is a unit testing framework inspired by JUnit, which was in turn an adaptation of Kent Beck’s Smalltalk testing framework. See https://pyunit.sourceforge.net/ for more information about PyUnit.The
difflib
module contains a class,SequenceMatcher
, which compares two sequences and computes the changes required to transform one sequence into the other. For example, this module can be used to write a tool similar to the Unix diff program, and in fact the sample programTools/scripts/ndiff.py
demonstrates how to write such a script.curses.panel
, a wrapper for the panel library, part of ncurses and of SYSV curses, was contributed by Thomas Gellekum. The panel library provides windows with the additional feature of depth. Windows can be moved higher or lower in the depth ordering, and the panel library figures out where panels overlap and which sections are visible.The PyXML package has gone through a few releases since Python 2.0, and Python 2.1 includes an updated version of the
xml
package. Some of the noteworthy changes include support for Expat 1.2 and later versions, the ability for Expat parsers to handle files in any encoding supported by Python, and various bugfixes for SAX, DOM, and theminidom
module.Ping also contributed another hook for handling uncaught exceptions.
sys.excepthook()
can be set to a callable object. When an exception isn’t caught by anytry
…except
blocks, the exception will be passed tosys.excepthook()
, which can then do whatever it likes. At the Ninth Python Conference, Ping demonstrated an application for this hook: printing an extended traceback that not only lists the stack frames, but also lists the function arguments and the local variables for each frame.Various functions in the
time
module, such asasctime()
andlocaltime()
, require a floating-point argument containing the time in seconds since the epoch. The most common use of these functions is to work with the current time, so the floating-point argument has been made optional; when a value isn’t provided, the current time will be used. For example, log file entries usually need a string containing the current time; in Python 2.1,time.asctime()
can be used, instead of the lengthiertime.asctime(time.localtime(time.time()))
that was previously required.This change was proposed and implemented by Thomas Wouters.
The
ftplib
module now defaults to retrieving files in passive mode, because passive mode is more likely to work from behind a firewall. This request came from the Debian bug tracking system, since other Debian packages useftplib
to retrieve files and then don’t work from behind a firewall. It’s deemed unlikely that this will cause problems for anyone, because Netscape defaults to passive mode and few people complain, but if passive mode is unsuitable for your application or network setup, callset_pasv(0)
on FTP objects to disable passive mode.Support for raw socket access has been added to the
socket
module, contributed by Grant Edwards.The
pstats
module now contains a simple interactive statistics browser for displaying timing profiles for Python programs, invoked when the module is run as a script. Contributed by Eric S. Raymond.A new implementation-dependent function,
sys._getframe([depth])
, has been added to return a given frame object from the current call stack.sys._getframe()
returns the frame at the top of the call stack; if the optional integer argument depth is supplied, the function returns the frame that is depth calls below the top of the stack. For example,sys._getframe(1)
returns the caller’s frame object.This function is only present in CPython, not in Jython or the .NET implementation. Use it for debugging, and resist the temptation to put it into production code.
Other Changes and Fixes¶
There were relatively few smaller changes made in Python 2.1 due to the shorter release cycle. A search through the CVS change logs turns up 117 patches applied, and 136 bugs fixed; both figures are likely to be underestimates. Some of the more notable changes are:
A specialized object allocator is now optionally available, that should be faster than the system
malloc()
and have less memory overhead. The allocator uses C’smalloc()
function to get large pools of memory, and then fulfills smaller memory requests from these pools. It can be enabled by providing the--with-pymalloc
option to the configure script; seeObjects/obmalloc.c
for the implementation details.Authors of C extension modules should test their code with the object allocator enabled, because some incorrect code may break, causing core dumps at runtime. There are a bunch of memory allocation functions in Python’s C API that have previously been just aliases for the C library’s
malloc()
andfree()
, meaning that if you accidentally called mismatched functions, the error wouldn’t be noticeable. When the object allocator is enabled, these functions aren’t aliases ofmalloc()
andfree()
any more, and calling the wrong function to free memory will get you a core dump. For example, if memory was allocated usingPyMem_New
, it has to be freed usingPyMem_Del()
, notfree()
. A few modules included with Python fell afoul of this and had to be fixed; doubtless there are more third-party modules that will have the same problem.The object allocator was contributed by Vladimir Marangozov.
The speed of line-oriented file I/O has been improved because people often complain about its lack of speed, and because it’s often been used as a naïve benchmark. The
readline()
method of file objects has therefore been rewritten to be much faster. The exact amount of the speedup will vary from platform to platform depending on how slow the C library’sgetc()
was, but is around 66%, and potentially much faster on some particular operating systems. Tim Peters did much of the benchmarking and coding for this change, motivated by a discussion in comp.lang.python.A new module and method for file objects was also added, contributed by Jeff Epler. The new method,
xreadlines()
, is similar to the existingxrange()
built-in.xreadlines()
returns an opaque sequence object that only supports being iterated over, reading a line on every iteration but not reading the entire file into memory as the existingreadlines()
method does. You’d use it like this:for line in sys.stdin.xreadlines(): # ... do something for each line ... ...
For a fuller discussion of the line I/O changes, see the python-dev summary for January 1–15, 2001 at https://mail.python.org/pipermail/python-dev/2001-January/.
A new method,
popitem()
, was added to dictionaries to enable destructively iterating through the contents of a dictionary; this can be faster for large dictionaries because there’s no need to construct a list containing all the keys or values.D.popitem()
removes a random(key, value)
pair from the dictionaryD
and returns it as a 2-tuple. This was implemented mostly by Tim Peters and Guido van Rossum, after a suggestion and preliminary patch by Moshe Zadka.Modules can now control which names are imported when
from module import *
is used, by defining an__all__
attribute containing a list of names that will be imported. One common complaint is that if the module imports other modules such assys
orstring
,from module import *
will add them to the importing module’s namespace. To fix this, simply list the public names in__all__
:# List public names __all__ = ['Database', 'open']
A stricter version of this patch was first suggested and implemented by Ben Wolfson, but after some python-dev discussion, a weaker final version was checked in.
Applying
repr()
to strings previously used octal escapes for non-printable characters; for example, a newline was'\012'
. This was a vestigial trace of Python’s C ancestry, but today octal is of very little practical use. Ka-Ping Yee suggested using hex escapes instead of octal ones, and using the\n
,\t
,\r
escapes for the appropriate characters, and implemented this new formatting.Syntax errors detected at compile-time can now raise exceptions containing the filename and line number of the error, a pleasant side effect of the compiler reorganization done by Jeremy Hylton.
C extensions which import other modules have been changed to use
PyImport_ImportModule()
, which means that they will use any import hooks that have been installed. This is also encouraged for third-party extensions that need to import some other module from C code.The size of the Unicode character database was shrunk by another 340K thanks to Fredrik Lundh.
Some new ports were contributed: MacOS X (by Steven Majewski), Cygwin (by Jason Tishler); RISCOS (by Dietmar Schwertberger); Unixware 7 (by Billy G. Allie).
And there’s the usual list of minor bugfixes, minor memory leaks, docstring edits, and other tweaks, too lengthy to be worth itemizing; see the CVS logs for the full details if you want them.
Acknowledgements¶
The author would like to thank the following people for offering suggestions on various drafts of this article: Graeme Cross, David Goodger, Jay Graves, Michael Hudson, Marc-André Lemburg, Fredrik Lundh, Neil Schemenauer, Thomas Wouters.


msilib
— Read and write Microsoft Installer files¶
Deprecated since version 3.11, removed in version 3.13.
This module is no longer part of the Python standard library. It was removed in Python 3.13 after being deprecated in Python 3.11. The removal was decided in PEP 594.
The last version of Python that provided the msilib
module was
Python 3.12.


Python Frequently Asked Questions

Theme
Auto
Light
Dark
Previous topic
Remote debugging attachment protocol
Next topic
General Python FAQ
This page
Report a bug
Improve this page
Show source
Navigation
index
modules
|
next
|
previous
|
Python
»
3.14.3 Documentation
»
Python Frequently Asked Questions
|
Theme
Auto
Light
Dark
|
Python Frequently Asked Questions
¶
General Python FAQ
Programming FAQ
Design and History FAQ
Library and Extension FAQ
Extending/Embedding FAQ
Python on Windows FAQ
Graphic User Interface FAQ
“Why is Python Installed on my Computer?” FAQ
Previous topic
Remote debugging attachment protocol
Next topic
General Python FAQ
This page
Report a bug
Improve this page
Show source
«
Navigation
index
modules
|
next
|
previous
|
Python
»
3.14.3 Documentation
»
Python Frequently Asked Questions
|
Theme
Auto
Light
Dark
|