There can be zero or more elif parts, and the else part is
optional. The keyword ‘elif‘ is short for ‘else if’, and is useful
to avoid excessive indentation. An if ... elif ...
elif ... sequence is a substitute for the switch or
case statements found in other languages.

The for statement in Python differs a bit from what you may be used
to in C or Pascal. Rather than always iterating over an arithmetic progression
of numbers (like in Pascal), or giving the user the ability to define both the
iteration step and halting condition (as C), Python’s for statement
iterates over the items of any sequence (a list or a string), in the order that
they appear in the sequence. For example (no pun intended):

If you need to modify the sequence you are iterating over while inside the loop
(for example to duplicate selected items), it is recommended that you first
make a copy. Iterating over a sequence does not implicitly make a copy. The
slice notation makes this especially convenient:

If you do need to iterate over a sequence of numbers, the built-in function
range() comes in handy. It generates arithmetic progressions:

>>> foriinrange(5):... print(i)...01234

The given end point is never part of the generated sequence; range(10) generates
10 values, the legal indices for items of a sequence of length 10. It
is possible to let the range start at another number, or to specify a different
increment (even negative; sometimes this is called the ‘step’):

In many ways the object returned by range() behaves as if it is a list,
but in fact it isn’t. It is an object which returns the successive items of
the desired sequence when you iterate over it, but it doesn’t really make
the list, thus saving space.

We say such an object is iterable, that is, suitable as a target for
functions and constructs that expect something from which they can
obtain successive items until the supply is exhausted. We have seen that
the for statement is such an iterator. The function list()
is another; it creates lists from iterables:

>>> list(range(5))[0, 1, 2, 3, 4]

Later we will see more functions that return iterables and take iterables as argument.

The break statement, like in C, breaks out of the smallest enclosing
for or while loop.

Loop statements may have an else clause; it is executed when the loop
terminates through exhaustion of the list (with for) or when the
condition becomes false (with while), but not when the loop is
terminated by a break statement. This is exemplified by the
following loop, which searches for prime numbers:

(Yes, this is the correct code. Look closely: the else clause belongs to
the for loop, not the if statement.)

When used with a loop, the else clause has more in common with the
else clause of a try statement than it does that of
if statements: a try statement’s else clause runs
when no exception occurs, and a loop’s else clause runs when no break
occurs. For more on the try statement and exceptions, see
Handling Exceptions.

The continue statement, also borrowed from C, continues with the next
iteration of the loop:

>>> fornuminrange(2,10):... ifnum%2==0:... print("Found an even number",num)... continue... print("Found a number",num)Found an even number 2Found a number 3Found an even number 4Found a number 5Found an even number 6Found a number 7Found an even number 8Found a number 9

The pass statement does nothing. It can be used when a statement is
required syntactically but the program requires no action. For example:

>>> whileTrue:... pass# Busy-wait for keyboard interrupt (Ctrl+C)...

This is commonly used for creating minimal classes:

>>> classMyEmptyClass:... pass...

Another place pass can be used is as a place-holder for a function or
conditional body when you are working on new code, allowing you to keep thinking
at a more abstract level. The pass is silently ignored:

The keyword def introduces a function definition. It must be
followed by the function name and the parenthesized list of formal parameters.
The statements that form the body of the function start at the next line, and
must be indented.

The first statement of the function body can optionally be a string literal;
this string literal is the function’s documentation string, or docstring.
(More about docstrings can be found in the section Documentation Strings.)
There are tools which use docstrings to automatically produce online or printed
documentation, or to let the user interactively browse through code; it’s good
practice to include docstrings in code that you write, so make a habit of it.

The execution of a function introduces a new symbol table used for the local
variables of the function. More precisely, all variable assignments in a
function store the value in the local symbol table; whereas variable references
first look in the local symbol table, then in the local symbol tables of
enclosing functions, then in the global symbol table, and finally in the table
of built-in names. Thus, global variables cannot be directly assigned a value
within a function (unless named in a global statement), although they
may be referenced.

The actual parameters (arguments) to a function call are introduced in the local
symbol table of the called function when it is called; thus, arguments are
passed using call by value (where the value is always an object reference,
not the value of the object). [1] When a function calls another function, a new
local symbol table is created for that call.

A function definition introduces the function name in the current symbol table.
The value of the function name has a type that is recognized by the interpreter
as a user-defined function. This value can be assigned to another name which
can then also be used as a function. This serves as a general renaming
mechanism:

Coming from other languages, you might object that fib is not a function but
a procedure since it doesn’t return a value. In fact, even functions without a
return statement do return a value, albeit a rather boring one. This
value is called None (it’s a built-in name). Writing the value None is
normally suppressed by the interpreter if it would be the only value written.
You can see it if you really want to using print():

>>> fib(0)>>> print(fib(0))None

It is simple to write a function that returns a list of the numbers of the
Fibonacci series, instead of printing it:

The return statement returns with a value from a function.
return without an expression argument returns None. Falling off
the end of a function also returns None.

The statement result.append(a) calls a method of the list object
result. A method is a function that ‘belongs’ to an object and is named
obj.methodname, where obj is some object (this may be an expression),
and methodname is the name of a method that is defined by the object’s type.
Different types define different methods. Methods of different types may have
the same name without causing ambiguity. (It is possible to define your own
object types and methods, using classes, see Classes)
The method append() shown in the example is defined for list objects; it
adds a new element at the end of the list. In this example it is equivalent to
result=result+[a], but more efficient.

giving one of the optional arguments:
ask_ok('OKtooverwritethefile?',2)

or even giving all arguments:
ask_ok('OKtooverwritethefile?',2,'Comeon,onlyyesorno!')

This example also introduces the in keyword. This tests whether or
not a sequence contains a certain value.

The default values are evaluated at the point of function definition in the
defining scope, so that

i=5deff(arg=i):print(arg)i=6f()

will print 5.

Important warning: The default value is evaluated only once. This makes a
difference when the default is a mutable object such as a list, dictionary, or
instances of most classes. For example, the following function accumulates the
arguments passed to it on subsequent calls:

deff(a,L=[]):L.append(a)returnLprint(f(1))print(f(2))print(f(3))

This will print

[1][1,2][1,2,3]

If you don’t want the default to be shared between subsequent calls, you can
write the function like this instead:

In a function call, keyword arguments must follow positional arguments.
All the keyword arguments passed must match one of the arguments
accepted by the function (e.g. actor is not a valid argument for the
parrot function), and their order is not important. This also includes
non-optional arguments (e.g. parrot(voltage=1000) is valid too).
No argument may receive a value more than once.
Here’s an example that fails due to this restriction:

When a final formal parameter of the form **name is present, it receives a
dictionary (see Mapping Types — dict) containing all keyword arguments except for
those corresponding to a formal parameter. This may be combined with a formal
parameter of the form *name (described in the next subsection) which
receives a tuple containing the positional arguments beyond the formal parameter
list. (*name must occur before **name.) For example, if we define a
function like this:

defcheeseshop(kind,*arguments,**keywords):print("-- Do you have any",kind,"?")print("-- I'm sorry, we're all out of",kind)forarginarguments:print(arg)print("-"*40)keys=sorted(keywords.keys())forkwinkeys:print(kw,":",keywords[kw])

Note that the list of keyword argument names is created by sorting the result
of the keywords dictionary’s keys() method before printing its contents;
if this is not done, the order in which the arguments are printed is undefined.

Finally, the least frequently used option is to specify that a function can be
called with an arbitrary number of arguments. These arguments will be wrapped
up in a tuple (see Tuples and Sequences). Before the variable number of arguments,
zero or more normal arguments may occur.

Normally, these variadic arguments will be last in the list of formal
parameters, because they scoop up all remaining input arguments that are
passed to the function. Any formal parameters which occur after the *args
parameter are ‘keyword-only’ arguments, meaning that they can only be used as
keywords rather than positional arguments.

The reverse situation occurs when the arguments are already in a list or tuple
but need to be unpacked for a function call requiring separate positional
arguments. For instance, the built-in range() function expects separate
start and stop arguments. If they are not available separately, write the
function call with the *-operator to unpack the arguments out of a list
or tuple:

Small anonymous functions can be created with the lambda keyword.
This function returns the sum of its two arguments: lambdaa,b:a+b.
Lambda functions can be used wherever function objects are required. They are
syntactically restricted to a single expression. Semantically, they are just
syntactic sugar for a normal function definition. Like nested function
definitions, lambda functions can reference variables from the containing
scope:

Here are some conventions about the content and formatting of documentation
strings.

The first line should always be a short, concise summary of the object’s
purpose. For brevity, it should not explicitly state the object’s name or type,
since these are available by other means (except if the name happens to be a
verb describing a function’s operation). This line should begin with a capital
letter and end with a period.

If there are more lines in the documentation string, the second line should be
blank, visually separating the summary from the rest of the description. The
following lines should be one or more paragraphs describing the object’s calling
conventions, its side effects, etc.

The Python parser does not strip indentation from multi-line string literals in
Python, so tools that process documentation have to strip indentation if
desired. This is done using the following convention. The first non-blank line
after the first line of the string determines the amount of indentation for
the entire documentation string. (We can’t use the first line since it is
generally adjacent to the string’s opening quotes so its indentation is not
apparent in the string literal.) Whitespace “equivalent” to this indentation is
then stripped from the start of all lines of the string. Lines that are
indented less should not occur, but if they occur all their leading whitespace
should be stripped. Equivalence of whitespace should be tested after expansion
of tabs (to 8 spaces, normally).

Function annotations are completely optional,
arbitrary metadata information about user-defined functions. Neither Python
itself nor the standard library use function annotations in any way; this
section just shows the syntax. Third-party projects are free to use function
annotations for documentation, type checking, and other uses.

Annotations are stored in the __annotations__ attribute of the function
as a dictionary and have no effect on any other part of the function. Parameter
annotations are defined by a colon after the parameter name, followed by an
expression evaluating to the value of the annotation. Return annotations are
defined by a literal ->, followed by an expression, between the parameter
list and the colon denoting the end of the def statement. The
following example has a positional argument, a keyword argument, and the return
value annotated with nonsense:

Now that you are about to write longer, more complex pieces of Python, it is a
good time to talk about coding style. Most languages can be written (or more
concise, formatted) in different styles; some are more readable than others.
Making it easy for others to read your code is always a good idea, and adopting
a nice coding style helps tremendously for that.

For Python, PEP 8 has emerged as the style guide that most projects adhere to;
it promotes a very readable and eye-pleasing coding style. Every Python
developer should read it at some point; here are the most important points
extracted for you:

Use 4-space indentation, and no tabs.

4 spaces are a good compromise between small indentation (allows greater
nesting depth) and large indentation (easier to read). Tabs introduce
confusion, and are best left out.

Wrap lines so that they don’t exceed 79 characters.

This helps users with small displays and makes it possible to have several
code files side-by-side on larger displays.

Use blank lines to separate functions and classes, and larger blocks of
code inside functions.

When possible, put comments on a line of their own.

Use docstrings.

Use spaces around operators and after commas, but not directly inside
bracketing constructs: a=f(1,2)+g(3,4).

Name your classes and functions consistently; the convention is to use
CamelCase for classes and lower_case_with_underscores for functions
and methods. Always use self as the name for the first method argument
(see A First Look at Classes for more on classes and methods).

Don’t use fancy encodings if your code is meant to be used in international
environments. Python’s default, UTF-8, or even plain ASCII work best in any
case.

Likewise, don’t use non-ASCII characters in identifiers if there is only the
slightest chance people speaking a different language will read or maintain
the code.