update at 2014.12.26
>>> x = int(raw_input("Please enter an integer: "))
Please enter an integer: 42
>>> if x < 0:
... x = 0
... print 'Negative changed to zero'
... elif x == 0:
... print 'Zero'
... elif x == 1:
... print 'Single'
... else:
... print 'More'
...
More
The keyword ‘
elif‘ is short for ‘else if’, and is useful to avoid excessive indentation.
# This is an exercise file
words = ['cat','dog','elephant']
for w in words:
print w, len(w)
>>> range(10)
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
>>> range(5, 10)
[5, 6, 7, 8, 9]
>>> range(0, 10, 3)
[0, 3, 6, 9]
>>> range(-10, -100, -30)
[-10, -40, -70]
To iterate over the indices of a sequence, you can combine range() andlen() as follows:
>>> a = ['Mary', 'had', 'a', 'little', 'lamb']
>>> for i in range(len(a)):
... print i, a[i]
...
0 Mary
1 had
2 a
3 little
4 lamb
>>> for n in range(2, 10):
... for x in range(2, n):
... if n % x == 0:
... print n, 'equals', x, '*', n/x
... break
... else:
... # loop fell through without finding a factor
... print n, 'is a prime number'
...
2 is a prime number
3 is a prime number
4 equals 2 * 2
5 is a prime number
6 equals 2 * 3
7 is a prime number
8 equals 2 * 4
9 equals 3 * 3
The
continue statement, also borrowed from C, continues with the next iteration of the loop:
>>> for num in range(2, 10):
... if num % 2 == 0:
... print "Found an even number", num
... continue
... print "Found a number", num
Found an even number 2
Found a number 3
Found an even number 4
Found a number 5
Found an even number 6
Found a number 7
Found an even number 8
Found 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:
>>> def initlog(*args):
... pass # Remember to implement this!
...
>>> def fib(n): # write Fibonacci series up to n
... """Print a Fibonacci series up to n."""
... a, b = 0, 1
... while a < n:
... print a,
... a, b = b, a+b
...
>>> # Now call the function we just defined:
... fib(2000)
0 1 1 2 3 5 8 13 21 34 55 89 144 233 377 610 987 1597
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 usingcall 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:
It is simple to write a function that returns a list of the numbers of theFibonacci series, instead of printing it:
>>> def fib(n):
... result=[]
... a,b=0,1
... while a < n:
... result.append(a)
... a,b=b,a+b
... return result
...
>>> fib(1000)
[0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144, 233, 377, 610, 987]
This example, as usual, demonstrates some new Python features:
Important warning: The default value is evaluated only once.
i = 5
def f(arg=i):
print arg
i = 6
f()
will print
5.
def f(a, L=[]):
L.append(a)
return L
print f(1)
print f(2)
print f(3)
This will print
[1]
[1, 2]
[1, 2, 3]
Functions can also be called using keyword arguments of the form kwarg=value. For instance, the following function:
def parrot(voltage, state='a stiff', action='voom', type='Norwegian Blue'):
print "-- This parrot wouldn't", action,
print "if you put", voltage, "volts through it."
print "-- Lovely plumage, the", type
print "-- It's", state, "!"
accepts one required argument (voltage) and three optional arguments(state,action, and type). This function can be called in any of the following ways:
parrot(1000) # 1 positional argument
parrot(voltage=1000) # 1 keyword argument
parrot(voltage=1000000, action='VOOOOOM') # 2 keyword arguments
parrot(action='VOOOOOM', voltage=1000000) # 2 keyword arguments
parrot('a million', 'bereft of life', 'jump') # 3 positional arguments
parrot('a thousand', state='pushing up the daisies') # 1 positional, 1 keyword
but all the following calls would be invalid:
parrot() # required argument missing
parrot(voltage=5.0, 'dead') # non-keyword argument after a keyword argument
parrot(110, voltage=220) # duplicate value for the same argument
parrot(actor='John Cleese') # unknown keyword argument
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.
When a final formal parameter of the form **nameis present, it receives a dictionary (seeMapping 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) whichreceives a tuple containing the positional arguments beyond the formal parameter list. (*name must occur before**name.) For example, if we define afunction like this:
def cheeseshop(kind, *arguments, **keywords):
print "-- Do you have any", kind, "?"
print "-- I'm sorry, we're all out of", kind
for arg in arguments:
print arg
print "-" * 40
keys = sorted(keywords.keys())
for kw in keys:
print kw, ":", keywords[kw]
It could be called like this:
cheeseshop("Limburger", "It's very runny, sir.",
"It's really very, VERY runny, sir.",
shopkeeper='Michael Palin',
client="John Cleese",
sketch="Cheese Shop Sketch")
and of course it would print:
-- Do you have any Limburger ?
-- I'm sorry, we're all out of Limburger
It's very runny, sir.
It's really very, VERY runny, sir.
----------------------------------------
client : John Cleese
shopkeeper : Michael Palin
sketch : Cheese Shop Sketch
def write_multiple_items(file, separator, *args):
file.write(separator.join(args))
不太懂。。。占个坑
There are emerging conventions about the content and formatting of documentationstrings.
文档说明
首行是简洁概要描述,不出现object的类型、名称;以大写字母开始,以句号结束
如果有其他内容,第二行是空行,然后另起一行给出描述object的详细参数说明
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 averb 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 expansionof tabs (to 8 spaces, normally).
Here is an example of a multi-line docstring:
>>> def my_function():
... """Do nothing, but document it.
...
... No, really, it doesn't do anything.
... """
... pass
...
>>> print my_function.__doc__
Do nothing, but document it.
No, really, it doesn't do anything.
For Python, PEP 8 has emerged as thestyle 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 pointsextracted 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 andlower_case_with_underscores for functionsand methods. Always use self as the name for the first method argument(seeA 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. Plain ASCII works best in any case.