mirror of
https://github.com/beyondx/Notes.git
synced 2026-02-03 18:33:26 +08:00
updated
This commit is contained in:
@@ -0,0 +1,22 @@
|
||||
Content-Type: text/x-zim-wiki
|
||||
Wiki-Format: zim 0.4
|
||||
Creation-Date: 2012-12-02T16:34:03+08:00
|
||||
|
||||
====== 1. Introduction ======
|
||||
Created Sunday 02 December 2012
|
||||
|
||||
===== 1. Introduction =====
|
||||
The “Python library” contains several different kinds of components.
|
||||
|
||||
It contains __data types__ that would normally be considered part of the “core” of a language, such as **numbers and lists**. For these types, the Python language core defines the form of **literals** and places some constraints on their semantics, but does **not fully define** the semantics. (On the other hand, the language core does define syntactic properties like the spelling and priorities of operators.)
|
||||
|
||||
The library also contains __built-in functions and exceptions__ — objects that can be used by all Python code //without the need of an import statement//. Some of these are defined by the core language, but many are not essential for the core semantics and are only described here.
|
||||
|
||||
The bulk of the __library__, however, consists of a collection of modules. There are many ways to dissect this collection. Some modules are written in C and __built in__** to the Python interpreter**; others are written in Python and imported in source form.
|
||||
|
||||
Some modules provide interfaces that are highly specific to Python, like printing a stack trace; some provide interfaces that are specific to particular operating systems, such as access to specific hardware; others provide interfaces that are specific to a particular application domain, like the World Wide Web. Some modules are available in all versions and ports of Python; others are only available when the underlying system supports or requires them; yet others are available only when a particular configuration option was chosen at the time when Python was compiled and installed.
|
||||
|
||||
This manual is organized **“from the inside out:”** it first describes the built-in data types, then the built-in functions and exceptions, and finally the modules, grouped in chapters of related modules. The ordering of the chapters as well as the ordering of the modules within each chapter is roughly from most relevant to least important.
|
||||
|
||||
|
||||
Let the show begin!
|
||||
@@ -0,0 +1,892 @@
|
||||
Content-Type: text/x-zim-wiki
|
||||
Wiki-Format: zim 0.4
|
||||
Creation-Date: 2012-12-02T16:37:06+08:00
|
||||
|
||||
====== 2. Built-in Functions ======
|
||||
Created Sunday 02 December 2012
|
||||
|
||||
The Python interpreter has a number of functions built into it that are __always available__. They are listed here in alphabetical order.
|
||||
|
||||
abs() divmod() input() open() staticmethod()
|
||||
all() enumerate() int() ord() str()
|
||||
any() eval() isinstance() pow() sum()
|
||||
basestring() execfile() issubclass() print() super()
|
||||
bin() file() iter() property() tuple()
|
||||
bool() filter() len() range() type()
|
||||
bytearray() float() list() raw_input() unichr()
|
||||
callable() format() locals() reduce() unicode()
|
||||
chr() frozenset() long() reload() vars()
|
||||
classmethod() getattr() map() repr() xrange()
|
||||
cmp() globals() max() reversed() zip()
|
||||
compile() hasattr() memoryview() round() __import__()
|
||||
complex() hash() min() set() apply()
|
||||
delattr() help() next() setattr() buffer()
|
||||
dict() hex() object() slice() coerce()
|
||||
dir() id() oct() sorted() intern()
|
||||
|
||||
===== abs(x) =====
|
||||
Return the absolute value of **a number**. The argument may be a plain or long integer or a floating point number. If the argument is a complex number, its magnitude is returned.
|
||||
|
||||
===== all(iterable) =====
|
||||
Return True if **all elements** of the iterable are true (or if the iterable is empty). Equivalent to:
|
||||
|
||||
def all(iterable):
|
||||
for element in iterable:
|
||||
if not element:
|
||||
return False
|
||||
return True
|
||||
New in version 2.5.
|
||||
|
||||
===== any(iterable) =====
|
||||
Return True if **any element** of the iterable is true. If the iterable is empty, return False. Equivalent to:
|
||||
|
||||
def any(iterable):
|
||||
for element in iterable:
|
||||
if element:
|
||||
return True
|
||||
return False
|
||||
New in version 2.5.
|
||||
|
||||
===== basestring() =====
|
||||
__This abstract type is the superclass for str and unicode. It cannot be called or instantiated__, but it can be used to test whether an object is an instance of str or unicode. **isinstance(obj, basestring)** is equivalent to isinstance(obj, (str, unicode)).
|
||||
basestring其实是一个抽象类,它是str和unicode的基类,不能被实例化。
|
||||
New in version 2.3.
|
||||
|
||||
===== bin(x) =====
|
||||
x需要为int或long类型,否则需要定义__index__()方法。
|
||||
Convert an __integer number__ to a binary string. The result is a valid Python expression. If x is not a Python int object, it has to define an **__index__()** method that returns an integer.
|
||||
|
||||
=== 实例: ===
|
||||
**>>> bin(123.22)**
|
||||
**Traceback (most recent call last):**
|
||||
** File "<stdin>", line 1, in <module>**
|
||||
**TypeError: 'float' object cannot be interpreted as an index**
|
||||
**>>>**
|
||||
|
||||
New in version 2.6.
|
||||
|
||||
===== bool([x]) =====
|
||||
Convert a value to a Boolean, using the standard truth testing procedure. If x is false or omitted, this returns **False**; otherwise it returns True. __bool is also a class__, which is a subclass of int. Class bool cannot be subclassed further. Its only instances are False and True.
|
||||
__False和True时class bool的实例。__
|
||||
New in version 2.2.1.
|
||||
|
||||
Changed in version 2.3: If no argument is given, this function returns False.
|
||||
|
||||
===== bytearray([source[, encoding[, errors]]]) =====
|
||||
Return a new array of bytes. The bytearray type __is a mutable sequence of integers in the range 0 <= x < 256__. It has most of the usual methods of mutable sequences, described in Mutable Sequence Types, as well as most methods that the str type has, see String Methods.
|
||||
|
||||
The optional source parameter can be used to initialize the array in a few different ways:
|
||||
|
||||
* If it is a **string**, you must also give the encoding (and optionally, errors) parameters; bytearray() then converts the string to bytes using str.encode().
|
||||
* If it is an **integer**, __the array will have that size__ and will be initialized with null bytes.
|
||||
* If it is an **object** conforming to the buffer interface, a read-only buffer of the object will be used to initialize the bytes array.
|
||||
* If it is an **iterable**, it must be an iterable of integers in the range 0 <= x < 256, which are used as the initial contents of the array.
|
||||
Without an argument, an array of **size 0** is created.
|
||||
|
||||
New in version 2.6.
|
||||
|
||||
===== callable(object) =====
|
||||
Return True if the object argument appears callable, False if not. If this returns true, it is still possible that a call fails, but if it is false, calling object will never succeed. Note that **classes are callable** (calling a class returns a new instance); class instances are callable if they have a __call__() method.
|
||||
|
||||
===== chr(i) =====
|
||||
Return **a string of one character** whose ASCII code is the integer i. For example, chr(97) returns the string 'a'. This is the inverse of **ord()**. The argument must be in the range [0..255], inclusive; ValueError will be raised if i is outside that range. See also unichr().
|
||||
|
||||
===== classmethod(function) =====
|
||||
Return a class method for function.
|
||||
|
||||
A class method receives the class as __implicit first argument__, just like an instance method receives the instance. To declare a class method, use this idiom:
|
||||
|
||||
class C:
|
||||
**@classmethod //不可少,否则调用时解释器不会自动将class传给f函数。**
|
||||
def f(cls, arg1, arg2, ...): ...
|
||||
The @classmethod form is a function **decorator** – see the description of function definitions in Function definitions for details.
|
||||
|
||||
It can be called either on the **class (such as C.f()) or on an instance (such as C().f())**. The instance is **ignored** except for its class. If a class method is called for a derived class, the derived **class object** is passed as the implied first argument.
|
||||
__classmethod修饰器,用来修饰一个class method。可以通过class或实例来调用该class method,解释器会将class或instance所属的class默认传给class method。__
|
||||
|
||||
Class methods are different than C++ or Java static methods. If you want those, see **staticmethod()** in this section.
|
||||
|
||||
For more information on class methods, consult the documentation on the standard type hierarchy in The standard type hierarchy.
|
||||
|
||||
New in version 2.2.
|
||||
|
||||
Changed in version 2.4: Function decorator syntax added.
|
||||
|
||||
===== cmp(x, y) =====
|
||||
Compare the two objects x and y and __return an integer__ according to the outcome. The return value is negative if x < y, zero if x == y and strictly positive if x > y.
|
||||
|
||||
===== compile(source, filename, mode[, flags[, dont_inherit]]) =====
|
||||
Compile the source into **a code object or AST object**. Code objects can be executed by an __exec__ statement or evaluated by a call to __eval().__ source can either be a string or an AST object. Refer to the ast module documentation for information on how to work with AST objects.
|
||||
|
||||
The filename argument should give the file from which the code was read; pass some recognizable value if it wasn’t read from a file ('<string>' is commonly used).
|
||||
|
||||
The mode argument specifies **what kind of code** must be compiled; it can be __'exec'__ if source consists of a sequence of statements, __'eval'__ if it consists of a single expression, or __'single'__ if it consists of a single interactive statement (in the latter case, expression statements that evaluate to something other than None will be printed).
|
||||
|
||||
The optional arguments flags and dont_inherit control which future statements (see PEP 236) affect the compilation of source. If neither is present (or both are zero) the code is compiled with those future statements that are in effect in the code that is calling compile. If the flags argument is given and dont_inherit is not (or is zero) then the future statements specified by the flags argument are used in addition to those that would be used anyway. If dont_inherit is a non-zero integer then the flags argument is it – the future statements in effect around the call to compile are ignored.
|
||||
|
||||
Future statements are specified by bits which can be bitwise ORed together to specify multiple statements. The bitfield required to specify a given feature can be found as the compiler_flag attribute on the _Feature instance in the __future__ module.
|
||||
|
||||
This function raises SyntaxError if the compiled source is invalid, and TypeError if the source contains null bytes.
|
||||
|
||||
Note When compiling **a string with multi-line code** in 'single' or 'eval' mode, input must be terminated by at least one newline character. This is to facilitate detection of incomplete and complete statements in the code module.
|
||||
Changed in version 2.3: The flags and dont_inherit arguments were added.
|
||||
|
||||
Changed in version 2.6: Support for compiling AST objects.
|
||||
|
||||
Changed in version 2.7: Allowed use of Windows and Mac newlines. Also input in 'exec' mode does not have to end in a newline anymore.
|
||||
|
||||
===== complex([real[, imag]]) =====
|
||||
Create a complex number with the value real + imag*j or convert a string or number to a complex number. If the first parameter is a string, it will be interpreted as a complex number and the function must be called without a second parameter. The second parameter can never be a string. Each argument may be any numeric type (including complex). If imag is omitted, it defaults to zero and the function serves as a numeric conversion function like int(), long() and float(). If both arguments are omitted, returns 0j.
|
||||
|
||||
Note When converting from a string, the string must not contain whitespace around the central + or - operator. For example, complex('1+2j') is fine, but complex('1 + 2j') raises ValueError.
|
||||
The complex type is described in Numeric Types — int, float, long, complex.
|
||||
|
||||
===== delattr(object, name) =====
|
||||
This is a relative of setattr(). The arguments are an object and a string. The string must be the name of one of the object’s attributes. The function deletes the named attribute, provided the object allows it. For example, **delattr(x, 'foobar')** is equivalent to **del x.foobar**.
|
||||
|
||||
===== dict(**kwarg) =====
|
||||
|
||||
===== dict(mapping, **kwarg) =====
|
||||
|
||||
===== dict(iterable, **kwarg) =====
|
||||
Create a new dictionary. The dict object is the dictionary class. See dict and Mapping Types — dict for documentation about this class.
|
||||
|
||||
For other containers see the built-in list, set, and tuple classes, as well as the collections module.
|
||||
|
||||
===== dir([object]) =====
|
||||
Without arguments, return the list of names in the current local scope. With an argument, attempt to return a list of valid attributes for that object.
|
||||
|
||||
If the object has a method named __dir__(), this method will be called and must return the list of attributes. This allows objects that implement a custom __getattr__() or __getattribute__() function to customize the way dir() reports their attributes.
|
||||
|
||||
If the object does not provide __dir__(), the function tries its best to gather information from the object’s __dict__ attribute, if defined, and from its type object. The resulting list is not necessarily complete, and may be inaccurate when the object has a custom __getattr__().
|
||||
|
||||
The default dir() mechanism behaves differently with different types of objects, as it attempts to produce the most relevant, rather than complete, information:
|
||||
|
||||
* If the object is a module object, the list contains the names of the module’s attributes.
|
||||
* If the object is a type or class object, the list contains the names of its attributes, and recursively of the attributes of its bases.
|
||||
* Otherwise, the list contains the object’s attributes’ names, the names of its class’s attributes, and recursively of the attributes of its class’s base classes.
|
||||
The resulting list is sorted alphabetically. For example:
|
||||
|
||||
>>>
|
||||
>>> import struct
|
||||
>>> dir() # show the names in the module namespace
|
||||
['__builtins__', '__doc__', '__name__', 'struct']
|
||||
>>> dir(struct) # show the names in the struct module
|
||||
['Struct', '__builtins__', '__doc__', '__file__', '__name__',
|
||||
'__package__', '_clearcache', 'calcsize', 'error', 'pack', 'pack_into',
|
||||
'unpack', 'unpack_from']
|
||||
>>> class Shape(object):
|
||||
def __dir__(self):
|
||||
return ['area', 'perimeter', 'location']
|
||||
>>> s = Shape()
|
||||
>>> dir(s)
|
||||
['area', 'perimeter', 'location']
|
||||
Note Because dir() is supplied primarily as a convenience for use at an interactive prompt, it tries to supply an interesting set of names more than it tries to supply a rigorously or consistently defined set of names, and its detailed behavior may change across releases. For example, metaclass attributes are not in the result list when the argument is a class.
|
||||
|
||||
===== divmod(a, b) =====
|
||||
Take two (non complex) numbers as arguments and return a pair of numbers consisting of their quotient and remainder when using long division. With mixed operand types, the rules for binary arithmetic operators apply. For plain and long integers, the result is the same as (a // b, a % b). For floating point numbers the result is (q, a % b), where q is usually math.floor(a / b) but may be 1 less than that. In any case q * b + a % b is very close to a, if a % b is non-zero it has the same sign as b, and 0 <= abs(a % b) < abs(b).
|
||||
|
||||
Changed in version 2.3: Using divmod() with complex numbers is deprecated.
|
||||
|
||||
===== enumerate(sequence, start=0) =====
|
||||
Return an enumerate object. sequence must be a sequence, an iterator, or some other object which supports iteration. The next() method of the iterator returned by enumerate() returns a tuple containing a count (from start which defaults to 0) and the values obtained from iterating over sequence:
|
||||
|
||||
>>>
|
||||
>>> seasons = ['Spring', 'Summer', 'Fall', 'Winter']
|
||||
>>> list(enumerate(seasons))
|
||||
[(0, 'Spring'), (1, 'Summer'), (2, 'Fall'), (3, 'Winter')]
|
||||
>>> list(enumerate(seasons, start=1))
|
||||
[(1, 'Spring'), (2, 'Summer'), (3, 'Fall'), (4, 'Winter')]
|
||||
Equivalent to:
|
||||
|
||||
def enumerate(sequence, start=0):
|
||||
n = start
|
||||
for elem in sequence:
|
||||
**yield n, elem**
|
||||
n += 1
|
||||
New in version 2.3.
|
||||
|
||||
Changed in version 2.6: The start parameter was added.
|
||||
|
||||
===== eval(expression[, globals[, locals]]) =====
|
||||
The arguments are a string and optional globals and locals. If provided, globals must be a dictionary. If provided, locals can be any mapping object.
|
||||
|
||||
Changed in version 2.4: formerly locals was required to be a dictionary.
|
||||
|
||||
The expression argument is parsed and evaluated as a Python expression (technically speaking, a condition list) using the globals and locals dictionaries as global and local namespace. If the globals dictionary is present and lacks ‘__builtins__’, the current globals are copied into globals before expression is parsed. This means that expression normally has full access to the standard __builtin__ module and restricted environments are propagated. If the locals dictionary is omitted it defaults to the globals dictionary. If both dictionaries are omitted, the expression is executed in the environment where eval() is called. The return value is the result of the evaluated expression. Syntax errors are reported as exceptions. Example:
|
||||
|
||||
>>>
|
||||
>>> x = 1
|
||||
>>> print eval('x+1')
|
||||
2
|
||||
This function can also be used to execute arbitrary code objects (such as those created by compile()). In this case pass a code object instead of a string. If the code object has been compiled with 'exec' as the mode argument, eval()‘s return value will be None.
|
||||
|
||||
Hints: dynamic execution of statements is supported by the exec statement. Execution of statements from a file is supported by the execfile() function. The globals() and locals() functions returns the current global and local dictionary, respectively, which may be useful to pass around for use by eval() or execfile().
|
||||
|
||||
See ast.literal_eval() for a function that can safely evaluate strings with expressions containing only literals.
|
||||
|
||||
===== execfile(filename[, globals[, locals]]) =====
|
||||
This function is similar to __the exec statement__, but parses a file instead of a string. It is different from the import statement in that it does not use the module administration — it reads the file unconditionally and does not create a new module. [1]
|
||||
|
||||
The arguments are a file name and two optional dictionaries. The file is parsed and evaluated as a sequence of Python statements (similarly to a module) using the globals and locals dictionaries as global and local namespace. If provided, locals can be any mapping object. Remember that **at module level, globals and locals are the same dictionary**. If two separate objects are passed as globals and locals, the code will be executed as if it were embedded in a class definition.
|
||||
|
||||
Changed in version 2.4: formerly locals was required to be a dictionary.
|
||||
|
||||
__If the locals dictionary is omitted it defaults to the globals dictionary. If both dictionaries are omitted, the expression is executed in the environment where execfile() is called.__ The return value is None.
|
||||
|
||||
Note The default locals act as described for function locals() below: modifications to the default locals dictionary should not be attempted. Pass an explicit locals dictionary if you need to see effects of the code on locals after function execfile() returns. execfile() cannot be used reliably to modify a function’s locals.
|
||||
|
||||
===== file(name[, mode[, buffering]]) =====
|
||||
file其实时class file的构造函数。
|
||||
Constructor function for the **file type**, described further in section File Objects. The constructor’s arguments are the same as those of the open() built-in function described below.
|
||||
|
||||
When opening a file, it’s preferable to use open() instead of invoking this constructor directly. file is more suited to type testing (for example, writing isinstance(f, file)).
|
||||
|
||||
New in version 2.2.
|
||||
|
||||
===== filter(function, iterable) =====
|
||||
Construct a list from those elements of iterable __for which function returns true__. iterable may be either a sequence, a container which supports iteration, or an iterator.
|
||||
|
||||
**If iterable is a string or a tuple, the result also has that type; otherwise it is always a list.**
|
||||
If function is None, the identity function is assumed, that is, all elements of iterable that are false are removed.
|
||||
|
||||
**如果可迭代对象是字符串或tuple,则结果也为字符串或tuple,其它的都为list。**
|
||||
**如果function为None,则结果为iterable中去掉判断为False的元素。**
|
||||
|
||||
Note that **filter(function, iterable) is equivalent to [item for item in iterable if function(item)]** if function is not None and [item for item in iterable if item] if function is None.
|
||||
|
||||
See **itertools.ifilter() and itertools.ifilterfalse() f**or iterator versions of this function, including a variation that filters for elements where the function returns false.
|
||||
|
||||
===== float([x]) =====
|
||||
Convert a string or a number to floating point.
|
||||
|
||||
If the argument is a string, it must contain a possibly signed decimal or floating point number, __possibly embedded in whitespace(空格, \t, \r, \n, \v, \f)__.
|
||||
|
||||
__如果x为string,则x只能为十进制整型和浮点型字符串(则是因为float函数不像int函数那样含有可选的base参数,__
|
||||
__可以猜测或指定数字的进制类型),同时可以包含空字符。__The argument may also be **[+|-]nan or [+|-]inf**.
|
||||
|
||||
Otherwise, the argument may be **a plain** or long integer or a floating point number, and a floating point number with the same value (within Python’s floating point precision) is returned. If no argument is given, returns 0.0.
|
||||
|
||||
Note When passing in a string, values for **NaN** and **Infinity** may be returned, depending on the underlying C library. Float accepts the strings **nan, inf and -inf** for **NaN** and **positive or negative infinity**. The case and a leading + are ignored as well as a leading - is ignored for NaN. Float always represents NaN and infinity as nan, inf or -inf.
|
||||
The float type is described in Numeric Types — int, float, long, complex.
|
||||
>>> float(__0xff__)
|
||||
255.0
|
||||
>>> float(__'0xff'__)
|
||||
Traceback (most recent call last):
|
||||
File "<stdin>", line 1, in <module>
|
||||
ValueError: invalid literal for float(): 0xff
|
||||
>>>
|
||||
>>> float('__+inf'__)
|
||||
inf
|
||||
>>> float('+nan')
|
||||
nan
|
||||
>>>
|
||||
>>> float(__'123'__)
|
||||
123.0
|
||||
>>> float(__'123\n\r\v'__)
|
||||
123.0
|
||||
>>>
|
||||
>>> float(__+nan__)
|
||||
Traceback (most recent call last):
|
||||
File "<stdin>", line 1, in <module>
|
||||
NameError: name **'nan' is not defined**
|
||||
>>>
|
||||
|
||||
|
||||
===== format(value[, format_spec]) =====
|
||||
Convert a value to a “formatted” representation, as controlled by **format_spec**. The interpretation of format_spec will depend on the type of the value argument, however there is a standard formatting syntax that is used by most built-in types: Format Specification Mini-Language.
|
||||
|
||||
Note format(value, format_spec) merely calls **value.__format__(format_spec)**.
|
||||
New in version 2.6.
|
||||
|
||||
===== frozenset([iterable]) =====
|
||||
Return a new frozenset object, optionally with elements taken from iterable. frozenset is a built-in class. See frozenset and Set Types — set, frozenset for documentation about this class.
|
||||
|
||||
For other containers see the built-in set, list, tuple, and dict classes, as well as the __collections__ module.
|
||||
|
||||
New in version 2.4.
|
||||
|
||||
===== getattr(object, name[, default]) =====
|
||||
Return the value of the named attribute of object. **name must be a string**. If the string is the name of one of the object’s attributes, the result is the value of that attribute. For example, getattr(x, 'foobar') is equivalent to x.foobar. If the named attribute does not exist, default is returned if provided, otherwise AttributeError is raised.
|
||||
|
||||
===== globals() =====
|
||||
Return a dictionary representing __the current global symbol table__. This is always the dictionary of the current module (inside a function or method, this is the module where it is **defined**, not the module from which it is called).
|
||||
|
||||
===== hasattr(object, name) =====
|
||||
The arguments are an object and a string. The result is True if the string is the name of one of the object’s attributes, False if not. (This is implemented by calling getattr(object, name) and seeing whether it raises an exception or not.)
|
||||
|
||||
===== hash(object) =====
|
||||
Return the hash value of the object (if it has one). **Hash values are integers**. They are used to quickly compare dictionary keys during a dictionary lookup. Numeric values that compare equal have the same hash value (even if they are of different types, as is the case for 1 and 1.0).
|
||||
|
||||
===== help([object]) =====
|
||||
Invoke the built-in help system. (This function is intended for interactive use.) If no argument is given, the interactive help system starts on the interpreter console. If the argument is a string, then the string is looked up as the name of a module, function, class, method, keyword, or documentation topic, and a help page is printed on the console. If the argument is any other kind of object, a help page on the object is generated.
|
||||
|
||||
This function is added to the built-in namespace by the site module.
|
||||
|
||||
New in version 2.2.
|
||||
|
||||
===== hex(x) =====
|
||||
Convert an integer number (of any size) to a hexadecimal string. The result is a valid Python expression.
|
||||
|
||||
Note To obtain a hexadecimal string representation for a float, use the __float.hex()__ method.
|
||||
Changed in version 2.4: Formerly only returned an unsigned literal.
|
||||
|
||||
===== id(object) =====
|
||||
Return the “identity” of an object. This is an integer (or long integer) which is guaranteed to be unique and constant for this object during its lifetime. Two objects with non-overlapping lifetimes may have the same id() value.
|
||||
|
||||
CPython implementation detail: This is **the address of the object in memory**.
|
||||
|
||||
===== input([prompt]) =====
|
||||
Equivalent to **eval(raw_input(prompt))**.
|
||||
|
||||
This function does not catch user errors. If the input is not syntactically valid, a SyntaxError will be raised. Other exceptions may be raised if there is an error during evaluation.
|
||||
|
||||
If the __readline__ module was loaded, then input() will use it to provide elaborate line editing and history features.
|
||||
|
||||
Consider using the **raw_input()** function for general input from users.
|
||||
|
||||
===== int(x=0) =====
|
||||
|
||||
===== int(x, base=10) =====
|
||||
Convert a number or string x to an integer, or return 0 if no arguments are given. If x is a number, it can be a plain integer, a long integer, or a floating point number. If x is floating point, the conversion __truncates towards zero__. If the argument is outside the integer range, the function returns a long object instead.
|
||||
|
||||
__如果x为number,则不需要为其指定base参数,因为int函数会根据x的前缀如0b, 0x等正确判断。如果x为float number则其必须为十进制。__
|
||||
|
||||
If x is not a number or if base is given, then x must be a string or Unicode object __representing an integer literal in radix base__.
|
||||
|
||||
__如果x为string,则其必须为整型数字字符串,不能为各种进制的小数字符串。__
|
||||
|
||||
Optionally, the literal can be preceded by + or - (with no space in between) and __surrounded by whitespace__. A base-n literal consists of the digits 0 to n-1, with **a to z (or A to Z)** having values __10 to 35__. The default base is 10. The allowed values are 0 and 2-36.
|
||||
|
||||
Base-2, -8, and -16 literals can be optionally **prefixed with 0b/0B, 0o/0O/0, or 0x/0X**, as with integer literals in code. __Base 0__ means to interpret the string exactly as an integer literal, so that the actual base is 2, 8, 10, or 16.
|
||||
|
||||
The integer type is described in Numeric Types — int, float, long, complex.
|
||||
>>> int("0xfff") **//默认为Base 10, 所以解码错误。**
|
||||
Traceback (most recent call last):
|
||||
File "<stdin>", line 1, in <module>
|
||||
ValueError: invalid literal for int() with __base 10__: '0xfff'
|
||||
>>> int("0xfff", 16)
|
||||
4095
|
||||
>>> int(0xfff.ff) __//如果x为float number,则其必须为十进制。__
|
||||
Traceback (most recent call last):
|
||||
File "<stdin>", line 1, in <module>
|
||||
AttributeError: 'int' object has no attribute 'ff'
|
||||
>>> int(111.22)
|
||||
111
|
||||
>>> int(0b111.11)
|
||||
File "<stdin>", line 1
|
||||
int(0b111.11)
|
||||
^
|
||||
SyntaxError: invalid syntax
|
||||
>>>
|
||||
>>> int("**0xfff.ff"**, 16)
|
||||
Traceback (most recent call last):
|
||||
File "<stdin>", line 1, in <module>
|
||||
ValueError: invalid literal for int() with base 16: '0xfff.ff'
|
||||
>>>
|
||||
|
||||
>>> int('22.33') __//如果x为string,则必须为整型数字字符串。__
|
||||
Traceback (most recent call last):
|
||||
File "<stdin>", line 1, in <module>
|
||||
ValueError: invalid literal for int() with base 10: '22.33'
|
||||
|
||||
===== isinstance(object, classinfo) =====
|
||||
Return true if the object argument is an instance of the classinfo argument, or of a (direct, indirect or virtual) subclass thereof. Also return true if classinfo is a type object (new-style class) and object is an object of that type or of a (direct, indirect or virtual) subclass thereof. If object is not a class instance or an object of the given type, the function always returns false. If classinfo is neither a class object nor a type object, it may be a tuple of class or type objects, or may recursively contain other such tuples (other sequence types are not accepted). If classinfo is not a class, type, or tuple of classes, types, and such tuples, a TypeError exception is raised.
|
||||
|
||||
Changed in version 2.2: Support for a tuple of type information was added.
|
||||
|
||||
===== issubclass(class, classinfo) =====
|
||||
Return true if class is a subclass (direct, indirect or virtual) of classinfo. A class is considered a subclass of itself. classinfo may be a tuple of class objects, in which case every entry in classinfo will be checked. In any other case, a TypeError exception is raised.
|
||||
|
||||
Changed in version 2.3: Support for a tuple of type information was added.
|
||||
|
||||
===== iter(o[, sentinel]) =====
|
||||
Return an iterator object. The first argument is interpreted very differently depending on the presence of the second argument. Without a second argument, o must be __a collection object__ which supports th**e iteration protocol** (the __iter__() method), or it must support **the sequence protocol** (the __getitem__() method with integer arguments starting at 0). If it does not support either of those protocols, TypeError is raised. If the second argument, sentinel, is given, then o must be __a callable object__. The iterator created in this case will **call o with no arguments for each call** to its next() method; if the value returned is __equal to sentinel__, StopIteration will be raised, otherwise the value will be returned.
|
||||
|
||||
如果没有使用第二个参数,则o必须为容器对象。否则,o必须为可调用对象。
|
||||
|
||||
One useful application of the second form of iter() is to read lines of a file until a certain line is reached. The following example reads a file until the readline() method returns an empty string:
|
||||
|
||||
with open('mydata.txt') as fp:
|
||||
for line in iter(fp.readline, ''):
|
||||
process_line(line)
|
||||
New in version 2.2.
|
||||
|
||||
===== len(s) =====
|
||||
Return the length (the number of items) of an object. The argument may be a sequence (string, tuple or list) or a mapping (dictionary).
|
||||
|
||||
===== list([iterable]) =====
|
||||
Return a list whose items are the same and in the same order as iterable‘s items. iterable may be either a sequence, a container that supports iteration, or an iterator object. If iterable is already a list, **a copy is made** and returned, similar to iterable[:]. For instance, list('abc') returns ['a', 'b', 'c'] and list( (1, 2, 3) ) returns [1, 2, 3]. If no argument is given, returns a new empty list, [].
|
||||
|
||||
list is a mutable sequence type, as documented in Sequence Types — str, unicode, list, tuple, bytearray, buffer, xrange. For other containers see the built in dict, set, and tuple classes, and the collections module.
|
||||
|
||||
===== locals() =====
|
||||
Update and return a dictionary representing the **current local symbol table**. Free variables are returned by locals() when it is called in function blocks, but not in class blocks.
|
||||
|
||||
Note The contents of this dictionary should not be modified; changes may not affect the values of local and free variables used by the interpreter.
|
||||
|
||||
===== long(x=0) =====
|
||||
|
||||
===== long(x, base=10) =====
|
||||
Convert a string or number to a long integer. If the argument is a string, it must contain a possibly signed number of arbitrary size, possibly embedded in whitespace. The base argument is interpreted in the same way as for int(), and may only be given when x is a string. Otherwise, the argument may be a plain or long integer or a floating point number, and a long integer with the same value is returned. Conversion of floating point numbers to integers truncates (towards zero). If no arguments are given, returns 0L.
|
||||
|
||||
The long type is described in Numeric Types — int, float, long, complex.
|
||||
|
||||
===== map(function, iterable, ...) =====
|
||||
Apply function to **every item of iterable** and return a list of the results. If additional iterable arguments are passed, function must take that many arguments and is applied to the items from all iterables in parallel. If one iterable is shorter than another it is assumed to be __extended with None items__. If function is None, the identity function is assumed; if there are multiple arguments, map() returns a list consisting of tuples containing the corresponding items from all iterables (a kind of transpose operation). The iterable arguments may be a sequence or any iterable object; the result is __always a list__.
|
||||
|
||||
===== max(iterable[, key]) =====
|
||||
|
||||
===== max(arg1, arg2, *args[, key]) =====
|
||||
Return the largest item in an iterable or the largest of two or more arguments.
|
||||
|
||||
If one positional argument is provided, iterable must be a non-empty iterable (such as a non-empty string, tuple or list). The largest item in the iterable is returned. If two or more positional arguments are provided, the largest of the positional arguments is returned.
|
||||
|
||||
The optional key argument specifies **a one-argument ordering function** like that used for list.sort(). The key argument, if supplied, must be __in keyword form__ (for example, max(a,b,c,key=func)).
|
||||
|
||||
Changed in version 2.5: Added support for the optional key argument.
|
||||
|
||||
===== memoryview(obj) =====
|
||||
Return a “memory view” object created from the given argument. See memoryview type for more information.
|
||||
|
||||
===== min(iterable[, key]) =====
|
||||
|
||||
===== min(arg1, arg2, *args[, key]) =====
|
||||
Return the smallest item in an iterable or the smallest of two or more arguments.
|
||||
|
||||
If one positional argument is provided, iterable must be a non-empty iterable (such as a non-empty string, tuple or list). The smallest item in the iterable is returned. If two or more positional arguments are provided, the smallest of the positional arguments is returned.
|
||||
|
||||
The optional key argument specifies a one-argument ordering function like that used for list.sort(). The key argument, if supplied, __must be in keyword form (__for example, min(a,b,c,key=func)).
|
||||
|
||||
Changed in version 2.5: Added support for the optional key argument.
|
||||
|
||||
===== next(iterator[, default]) =====
|
||||
Retrieve the next item from the iterator by calling its next() method. If default is given, it is returned if the iterator is exhausted, otherwise StopIteration is raised.
|
||||
|
||||
New in version 2.6.
|
||||
|
||||
===== object() =====
|
||||
Return a new featureless object. object is a base for all new style classes. It has the methods that are common to all instances of new style classes.
|
||||
|
||||
New in version 2.2.
|
||||
|
||||
Changed in version 2.3: This function does not accept any arguments. Formerly, it accepted arguments but ignored them.
|
||||
|
||||
===== oct(x) =====
|
||||
Convert an integer number (of any size) to an octal string. The result is a valid Python expression.
|
||||
|
||||
Changed in version 2.4: Formerly only returned an unsigned literal.
|
||||
|
||||
===== open(name[, mode[, buffering]]) =====
|
||||
Open a file, returning an object of the **file type** described in section File Objects. If the file cannot be opened, __IOError__ is raised. When opening a file, it’s preferable to use open() instead of invoking the file constructor directly.
|
||||
|
||||
The first two arguments are the same as for stdio‘s fopen(): name is the file name to be opened, and mode is a string indicating how the file is to be opened.
|
||||
|
||||
The most commonly-used values of mode are __'r'__ for reading, __'w'__ for writing (**truncating the file** if it already exists), and __'a'__ for appending (which on some Unix systems means that all writes append to the end of the file regardless of the current seek position). If mode is omitted, __it defaults to 'r'__. The default is to use __text mode__, which may convert '\n' characters to a platform-specific representation on writing and back on reading. Thus, when opening a binary file, you should append __'b'__ to the mode value to open the file in binary mode, which will improve portability. (Appending 'b' is useful even on systems that don’t treat binary and text files differently, where it serves as documentation.) See below for more possible values of mode.
|
||||
|
||||
The optional buffering argument specifies the file’s desired buffer size: __0 means unbuffered, 1 means line buffered, any other positive value means use a buffer of (approximately) that size.__ A negative buffering means to use **the system default**, which is usually line buffered for tty devices and fully buffered for other files. If omitted, the system default is used. [2]
|
||||
|
||||
Modes **'r+', 'w+' and 'a+'** open the file for updating (note that __'w+' truncates the file__). Append 'b' to the mode to open the file in binary mode, on systems that differentiate between binary and text files; on systems that don’t have this distinction, adding the 'b' has no effect.
|
||||
|
||||
In addition to the standard **fopen()** values mode may be 'U' or 'rU'. Python is usually built with universal newlines support; supplying 'U' opens the file as a text file, but lines may be terminated by any of the following: the Unix end-of-line convention '\n', the Macintosh convention '\r', or the Windows convention '\r\n'. All of these external representations are seen as '\n' by the Python program. If Python is built without universal newlines support a mode with 'U' is the same as normal text mode. Note that file objects so opened also have an attribute called newlines which has a value of None (if no newlines have yet been seen), '\n', '\r', '\r\n', or a tuple containing all the newline types seen.
|
||||
|
||||
Python enforces that the mode, after stripping 'U', begins with 'r', 'w' or 'a'.
|
||||
|
||||
Python provides many file handling modules including __fileinput, os, os.path, tempfile, and shutil__.
|
||||
|
||||
Changed in version 2.5: Restriction on first letter of mode string introduced.
|
||||
|
||||
===== ord(c) =====
|
||||
Given a string of length one, return an integer representing the Unicode code point of the character when the argument is a unicode object, or the value of the byte when the argument is an 8-bit string. For example, ord('a') returns the integer 97, ord(u'\u2020') returns 8224. This is the inverse of chr() for 8-bit strings and of unichr() for unicode objects. If a unicode argument is given and Python was built with UCS2 Unicode, then the character’s code point must be in the range [0..65535] inclusive; otherwise the string length is two, and a TypeError will be raised.
|
||||
|
||||
===== pow(x, y[, z]) =====
|
||||
Return x to the power y; if z is present, return **x to the power y, modulo z** (computed more efficiently than pow(x, y) % z). The two-argument form pow(x, y) is equivalent to using the power operator: **x**y**.
|
||||
|
||||
The arguments must have numeric types. With mixed operand types, the coercion rules for binary arithmetic operators apply. For int and long int operands, the result has the same type as the operands (after coercion) unless the second argument is negative; in that case, all arguments are converted to float and a float result is delivered. For example, 10**2 returns 100, but 10**-2 returns 0.01. (This last feature was added in Python 2.2. In Python 2.1 and before, if both arguments were of integer types and the second argument was negative, an exception was raised.) If the second argument is negative, the third argument must be omitted. If z is present, x and y must be of integer types, and y must be non-negative. (This restriction was added in Python 2.2. In Python 2.1 and before, floating 3-argument pow() returned platform-dependent results depending on floating-point rounding accidents.)
|
||||
|
||||
===== print(*objects, sep=' ', end='\n', file=sys.stdout) =====
|
||||
|
||||
Print objects to the stream file, separated by sep and followed by end. sep, end and file, if present, must be given as keyword arguments.
|
||||
|
||||
All non-keyword arguments are converted to strings like **str()** does and written to the stream, separated by sep and followed by end. Both sep and end must be strings; they can also be None, which means to use the default values. If no objects are given, print() will just write end.
|
||||
|
||||
The file argument must be an object with a write(string) method; if it is not present or None, sys.stdout will be used. Output buffering is determined by file. Use **file.flush()** to ensure, for instance, immediate appearance on a screen.
|
||||
|
||||
Note This function is **not normally available as a built-in** since the name print is recognized as the **print statement**.
|
||||
该函数一般不能直接使用,因为pythn2中的print是一个statement。
|
||||
To disable the statement and use the print() function, use this future statement at the top of your module:
|
||||
__from __future__ import print_function__
|
||||
New in version 2.6.
|
||||
|
||||
===== property([fget[, fset[, fdel[, doc]]]]) =====
|
||||
Return a property attribute for new-style classes (classes that derive from object).
|
||||
|
||||
fget is a function for getting an attribute value, likewise fset is a function for setting, and fdel a function for del’ing, an attribute. Typical use is to define a managed attribute x:
|
||||
|
||||
class C(object):
|
||||
def __init__(self):
|
||||
self._x = None
|
||||
|
||||
def getx(self):
|
||||
return self._x
|
||||
def setx(self, value):
|
||||
self._x = value
|
||||
def delx(self):
|
||||
del self._x
|
||||
__x = property(getx, setx, delx, "I'm the 'x' property.")__
|
||||
If then c is an instance of C, **c.x will invoke the getter, c.x = value will invoke the setter and del c.x the deleter**.
|
||||
|
||||
If given, doc will be the docstring of the property attribute(例如上面的最后一行字符串). Otherwise, the property will copy fget‘s docstring (if it exists). This makes it possible to create **read-only properties** easily using property() as a decorator:
|
||||
|
||||
class Parrot(object):
|
||||
def __init__(self):
|
||||
self._voltage = 100000
|
||||
|
||||
__@property //生成一个read-only properity。__
|
||||
def voltage(self):
|
||||
"""Get the current voltage."""
|
||||
return self._voltage
|
||||
turns the voltage() method into a “getter” for a read-only attribute with the same name.
|
||||
|
||||
A property object has __getter, setter, and deleter__ methods usable as decorators that create a copy of the property with the corresponding accessor function set to the decorated function. This is best explained with an example:
|
||||
|
||||
class C(object):
|
||||
def __init__(self):
|
||||
self._x = None
|
||||
|
||||
@property //property装饰器使修饰的函数x变为property object,默认生成一个read-only properity。
|
||||
def x(self):
|
||||
"""I'm the 'x' property."""
|
||||
return self._x
|
||||
|
||||
__@x__.setter //调用property object的setter方法。
|
||||
__def x__(self, value):
|
||||
self._x = value
|
||||
|
||||
@x.deleter
|
||||
def x(self): //注意没有参数,x就暗示了属性的类型。
|
||||
del self._x
|
||||
This code is exactly equivalent to the first example. Be sure to give the additional functions **the same name as the original** property (x in this case.)
|
||||
|
||||
The returned property also has the attributes fget, fset, and fdel corresponding to the constructor arguments.
|
||||
|
||||
New in version 2.2.
|
||||
|
||||
Changed in version 2.5: Use fget‘s docstring if no doc given.
|
||||
|
||||
Changed in version 2.6: The getter, setter, and deleter attributes were added.
|
||||
|
||||
===== range(stop) =====
|
||||
|
||||
===== range(start, stop[, step]) =====
|
||||
This is a versatile function to create lists containing arithmetic progressions. It is most often used in __for loops__. The arguments must be plain integers. If the step argument is omitted, it defaults to 1. If the start argument is omitted, it defaults to 0. The full form returns a list of plain integers [start, start + step, start + 2 * step, ...]. If step is positive, the last element is the largest start + i * step less than stop; if step is negative, the last element is the smallest start + i * step greater than stop. step must not be zero (or else ValueError is raised). Example:
|
||||
|
||||
>>>
|
||||
>>> range(10)
|
||||
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
|
||||
>>> range(1, 11)
|
||||
[1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
|
||||
>>> range(0, 30, 5)
|
||||
[0, 5, 10, 15, 20, 25]
|
||||
>>> range(0, 10, 3)
|
||||
[0, 3, 6, 9]
|
||||
>>> range(0, -10, -1)
|
||||
[0, -1, -2, -3, -4, -5, -6, -7, -8, -9]
|
||||
>>> range(0)
|
||||
[]
|
||||
>>> range(1, 0)
|
||||
[]
|
||||
|
||||
===== raw_input([prompt]) =====
|
||||
If the prompt argument is present, it is written to standard output __without a trailing newline__. The function then reads a line from input, __converts it to a string (stripping a trailing newline)__, and returns that. When EOF is read, EOFError is raised. Example:
|
||||
|
||||
>>>
|
||||
>>> s = raw_input('--> ')
|
||||
--> Monty Python's Flying Circus
|
||||
>>> s
|
||||
"Monty Python's Flying Circus"
|
||||
If the readline module was loaded, then raw_input() will use it to provide elaborate line editing and history features.
|
||||
|
||||
===== reduce(function, iterable[, initializer]) =====
|
||||
Apply function of __two arguments__ cumulatively to the items of iterable, from left to right, so as to reduce the iterable to a single value. For example, reduce(lambda x, y: x+y, [1, 2, 3, 4, 5]) calculates ((((1+2)+3)+4)+5). **The left argument, x, is the **__accumulated value__** and the right argument, y, is the update value from the iterable**. If the optional initializer is present, it is placed before the items of the iterable in the calculation, and serves as a default when the iterable is empty. If initializer is not given and iterable contains only one item, the first item is returned. Roughly equivalent to:
|
||||
|
||||
def reduce(function, iterable, initializer=None):
|
||||
it = iter(iterable)
|
||||
if initializer is None:
|
||||
try:
|
||||
initializer = next(it)
|
||||
except StopIteration:
|
||||
raise TypeError('reduce() of empty sequence with no initial value')
|
||||
**accum_value** = initializer
|
||||
for x in it:
|
||||
accum_value = function(accum_value, x)
|
||||
return accum_value
|
||||
|
||||
===== reload(module) =====
|
||||
Reload a previously imported module. The argument must be **a module object**, so it must have been successfully imported before. This is useful if you have **edited the module source file** using an external editor and want to try out the new version without leaving the Python interpreter. The return value is the module object (the same as the module argument).
|
||||
|
||||
When reload(module) is executed:
|
||||
|
||||
Python modules’ code is recompiled and the module-level code reexecuted, defining a new set of objects which are bound to names in the module’s dictionary. The init function of extension modules is not called a second time.
|
||||
As with all other objects in Python the old objects are only reclaimed after their reference counts drop to zero.
|
||||
The names in the module namespace are updated to point to any new or changed objects.
|
||||
Other references to the old objects (such as names external to the module) are not rebound to refer to the new objects and must be updated in each namespace where they occur if that is desired.
|
||||
|
||||
There are a number of other caveats:
|
||||
|
||||
If a module is syntactically correct but its initialization fails, the first import statement for it does not bind its name locally, but does store a (partially initialized) module object in sys.modules. To reload the module you must first import it again (this will bind the name to the partially initialized module object) before you can reload() it.
|
||||
|
||||
When a module is reloaded, its dictionary (containing the module’s global variables) is retained. Redefinitions of names will override the old definitions, so this is generally not a problem. If the new version of a module does not define a name that was defined by the old version, the old definition remains. This feature can be used to the module’s advantage if it maintains a global table or cache of objects — with a try statement it can test for the table’s presence and skip its initialization if desired:
|
||||
|
||||
try:
|
||||
cache
|
||||
except NameError:
|
||||
cache = {}
|
||||
It is legal though generally not very useful to reload built-in or dynamically loaded modules, except for sys, __main__ and __builtin__. In many cases, however, extension modules are not designed to be initialized more than once, and may fail in arbitrary ways when reloaded.
|
||||
|
||||
If a module imports objects from another module using from ... import ..., calling reload() for the other module does not redefine the objects imported from it — one way around this is to re-execute the from statement, another is to use import and qualified names (module.*name*) instead.
|
||||
|
||||
If a module instantiates instances of a class, reloading the module that defines the class does not affect the method definitions of the instances — they continue to use the old class definition. The same is true for derived classes.
|
||||
|
||||
===== repr(object) =====
|
||||
Return a string containing **a printable representation of an object**. This is the same value yielded by conversions (reverse quotes). It is sometimes useful to be able to access this operation as an ordinary function. For many types, this function makes an attempt to return a string that would yield an object with the same value when passed to eval(), otherwise the representation is a string enclosed in angle brackets that contains the name of the type of the object together with additional information often including the name and address of the object. A class can control what this function returns for its instances by defining a __repr__() method.
|
||||
|
||||
===== reversed(seq) =====
|
||||
__Return a reverse iterator.__ seq must be an object which has a __reversed__() method or supports **the sequence protocol** (the __len__() method and the __getitem__() method with integer arguments starting at 0).
|
||||
|
||||
New in version 2.4.
|
||||
|
||||
Changed in version 2.6: Added the possibility to write a custom __reversed__() method.
|
||||
|
||||
===== round(number[, ndigits]) =====
|
||||
Return the floating point value number rounded to **ndigits digits after the decimal point.** If ndigits is omitted, it defaults to zero. The result is a floating point number. Values are rounded to the closest multiple of 10 to the power minus ndigits; if two multiples are equally close, rounding is done away from 0 (so. for example, round(0.5) is 1.0 and round(-0.5) is -1.0).
|
||||
|
||||
Note The behavior of round() for floats can be surprising: for example, round(2.675, 2) gives 2.67 instead of the expected 2.68. This is not a bug: it’s a result of the fact that most decimal fractions can’t be represented exactly as a float. See Floating Point Arithmetic: Issues and Limitations for more information.
|
||||
|
||||
===== set([iterable]) =====
|
||||
Return a new set object, optionally with elements taken from iterable. set is a built-in class. See set and Set Types — set, frozenset for documentation about this class.
|
||||
|
||||
For other containers see the built-in frozenset, list, tuple, and dict classes, as well as the collections module.
|
||||
|
||||
New in version 2.4.
|
||||
|
||||
===== setattr(object, name, value) =====
|
||||
This is the counterpart of getattr(). The arguments are an object, a string and an arbitrary value. The string may name an existing attribute or a new attribute. The function assigns the value to the attribute, provided the object allows it. For example, setattr(x, 'foobar', 123) is equivalent to x.foobar = 123.
|
||||
|
||||
===== slice(stop) =====
|
||||
|
||||
===== slice(start, stop[, step]) =====
|
||||
Return a slice object representing the set of indices specified by **range(start, stop, step)**. The start and step arguments default to None. Slice objects have read-only data attributes start, stop and step which merely return the argument values (or their default). They have no other explicit functionality; however they are used by Numerical Python and other third party extensions. Slice objects are also generated when extended indexing syntax is used. For example: a[start:stop:step] or a[start:stop, i]. See itertools.islice() for an alternate version that returns an iterator.
|
||||
|
||||
===== sorted(iterable[, cmp[, key[, reverse]]]) =====
|
||||
Return __a new sorted list__ from the items in iterable.
|
||||
|
||||
The optional arguments **cmp, key, and reverse** have the same meaning as those for the list.sort() method (described in section Mutable Sequence Types).
|
||||
|
||||
cmp specifies __a custom comparison function of two arguments__ (iterable elements) which should __return a negative, zero or positive number__ depending on whether the first argument is considered smaller than, equal to, or larger than the second argument: cmp=lambda x,y: cmp(x.lower(), y.lower()). The default value is None.
|
||||
|
||||
key specifies a function of one argument that is used to **extract a comparison key from each list element**: key=str.lower. The default value is None (compare the elements directly).
|
||||
|
||||
reverse is a boolean value. If set to True, then the list elements are sorted as if each comparison were reversed.
|
||||
|
||||
In general, the key and reverse conversion processes are much faster than specifying an equivalent cmp function. This is because cmp is called multiple times for each list element while key and reverse touch each element only once. Use **functools.cmp_to_key()** to convert an old-style cmp function to a key function.
|
||||
|
||||
For sorting examples and a brief sorting tutorial, see Sorting HowTo.
|
||||
|
||||
New in version 2.4.
|
||||
|
||||
===== staticmethod(function) =====
|
||||
Return a static method for function.
|
||||
|
||||
A static method does not receive an implicit first argument. To declare a static method, use this idiom:
|
||||
|
||||
class C:
|
||||
@staticmethod
|
||||
def f(arg1, arg2, ...): ...
|
||||
The @staticmethod form is a function decorator – see the description of function definitions in Function definitions for details.
|
||||
|
||||
It can be called either on the class (such as C.f()) or on an instance (such as C().f()). The instance is ignored except for its class.
|
||||
|
||||
Static methods in Python are similar to those found in Java or C++. Also see classmethod() for a variant that is useful for creating alternate class constructors.
|
||||
|
||||
For more information on static methods, consult the documentation on the standard type hierarchy in The standard type hierarchy.
|
||||
|
||||
New in version 2.2.
|
||||
|
||||
Changed in version 2.4: Function decorator syntax added.
|
||||
|
||||
===== str(object='') =====
|
||||
Return a string containing a nicely printable representation of an object. For strings, this returns the string itself. The difference with repr(object) is that str(object) does not always attempt to return a string that is acceptable to eval(); its goal is to return a printable string. If no argument is given, returns the empty string, ''.
|
||||
|
||||
For more information on strings see Sequence Types — str, unicode, list, tuple, bytearray, buffer, xrange which describes sequence functionality (strings are sequences), and also the string-specific methods described in the String Methods section. To output formatted strings use template strings or the % operator described in the String Formatting Operations section. In addition see the String Services section. See also unicode().
|
||||
|
||||
===== sum(iterable[, start]) =====
|
||||
Sums start and the items of an iterable from left to right and returns the total. start defaults to 0. The iterable‘s items are normally numbers, and the start value is not allowed to be a string.
|
||||
|
||||
For some use cases, there are good alternatives to sum(). The preferred, fast way to concatenate a sequence of strings is by calling __''.join(sequence)__. To add floating point values with extended precision, see math.fsum(). To concatenate a series of iterables, consider using itertools.chain().
|
||||
|
||||
New in version 2.3.
|
||||
|
||||
===== super(type[, object-or-type]) =====
|
||||
Return a proxy object that delegates method calls to a parent or sibling class of type. This is useful for accessing inherited methods that have been overridden in a class. The search order is same as that used by getattr() except that the type itself is skipped.
|
||||
|
||||
The ____mro____ attribute of the type lists **the method resolution search order** used by both getattr() and super(). The attribute is dynamic and can change whenever the inheritance hierarchy is updated.
|
||||
|
||||
If the second argument is omitted, the super object returned is unbound. If the second argument is an object, isinstance(obj, type) must be true. If the second argument is a type, issubclass(type2, type) must be true (this is useful for classmethods).
|
||||
|
||||
Note super() only works for new-style classes.
|
||||
There are two typical use cases for super. In a class hierarchy with single inheritance, **super can be used to refer to parent classes **__without naming them explicitly__, thus making the code more maintainable. This use closely parallels the use of super in other programming languages.
|
||||
|
||||
The second use case is to support __cooperative multiple inheritance in a dynamic execution environment__. This use case is unique to Python and is not found in statically compiled languages or languages that only support single inheritance. This makes it possible to implement “diamond diagrams” where multiple base classes implement the same method. Good design dictates that this method have the same calling signature in every case (because the order of calls is determined at runtime, because that order adapts to changes in the class hierarchy, and because that order can include sibling classes that are unknown prior to runtime).
|
||||
|
||||
For both use cases, a typical superclass call looks like this:
|
||||
|
||||
class C(B):
|
||||
def method(self, arg):
|
||||
super(C, self).method(arg)
|
||||
Note that super() is implemented as part of the binding process for explicit dotted attribute lookups such as super().__getitem__(name). It does so by implementing its own __getattribute__() method for searching classes in a predictable order that supports cooperative multiple inheritance. Accordingly, super() is undefined for implicit lookups using statements or operators such as super()[name].
|
||||
|
||||
Also note that super() is not limited to use inside methods. The two argument form specifies the arguments exactly and makes the appropriate references.
|
||||
|
||||
For practical suggestions on how to design cooperative classes using super(), see guide to using super().
|
||||
|
||||
New in version 2.2.
|
||||
|
||||
===== tuple([iterable]) =====
|
||||
Return a tuple whose items are the same and in the same order as iterable‘s items. iterable may be a sequence, a container that supports iteration, or an iterator object. If iterable is already a tuple, it is returned unchanged. For instance, tuple('abc') returns ('a', 'b', 'c') and tuple([1, 2, 3]) returns (1, 2, 3). If no argument is given, returns a new empty tuple, ().
|
||||
|
||||
tuple is an immutable sequence type, as documented in Sequence Types — str, unicode, list, tuple, bytearray, buffer, xrange. For other containers see the built in dict, list, and set classes, and the collections module.
|
||||
|
||||
===== type(object) =====
|
||||
|
||||
===== type(name, bases, dict) =====
|
||||
With one argument, return the type of an object. The return value is a type object. The isinstance() built-in function is recommended for testing the type of an object.
|
||||
|
||||
With three arguments, return a new type object. This is essentially a dynamic form of the class statement. The name string is the class name and becomes the __name__ attribute; the bases tuple itemizes the base classes and becomes the __bases__ attribute; and the dict dictionary is the namespace containing definitions for class body and becomes the __dict__ attribute. For example, the following two statements create identical type objects:
|
||||
|
||||
>>>
|
||||
>>> class X(object):
|
||||
... a = 1
|
||||
...
|
||||
>>> X = type('X', (object,), dict(a=1))
|
||||
New in version 2.2.
|
||||
|
||||
===== unichr(i) =====
|
||||
Return the Unicode string of one character whose Unicode code is the integer i. For example, unichr(97) returns the string u'a'. This is the inverse of ord() for Unicode strings. The valid range for the argument depends how Python was configured – it may be either UCS2 [0..0xFFFF] or UCS4 [0..0x10FFFF]. ValueError is raised otherwise. For ASCII and 8-bit strings see chr().
|
||||
|
||||
New in version 2.0.
|
||||
|
||||
===== unicode(object='') =====
|
||||
|
||||
===== unicode(object[, encoding[, errors]]) =====
|
||||
Return the Unicode string version of object using one of the following modes:
|
||||
|
||||
If encoding and/or errors are given, unicode() will decode the object which can either be an 8-bit string or a character buffer using the codec for encoding. The encoding parameter is a string giving the name of an encoding; if the encoding is not known, LookupError is raised. Error handling is done according to errors; this specifies the treatment of characters which are invalid in the input encoding. If errors is 'strict' (the default), a ValueError is raised on errors, while a value of 'ignore' causes errors to be silently ignored, and a value of 'replace' causes the official Unicode replacement character, U+FFFD, to be used to replace input characters which cannot be decoded. See also the codecs module.
|
||||
|
||||
If no optional parameters are given, unicode() will mimic the behaviour of str() except that it returns Unicode strings instead of 8-bit strings. More precisely, if object is a Unicode string or subclass it will return that Unicode string without any additional decoding applied.
|
||||
|
||||
For objects which provide a __unicode__() method, it will call this method without arguments to create a Unicode string. For all other objects, the 8-bit string version or representation is requested and then converted to a Unicode string using the codec for the default encoding in 'strict' mode.
|
||||
|
||||
For more information on Unicode strings see Sequence Types — str, unicode, list, tuple, bytearray, buffer, xrange which describes sequence functionality (Unicode strings are sequences), and also the string-specific methods described in the String Methods section. To output formatted strings use template strings or the % operator described in the String Formatting Operations section. In addition see the String Services section. See also str().
|
||||
|
||||
New in version 2.0.
|
||||
|
||||
Changed in version 2.2: Support for __unicode__() added.
|
||||
|
||||
===== vars([object]) =====
|
||||
Return the __dict__ attribute for a module, class, instance, or any other object with a __dict__ attribute.
|
||||
|
||||
Objects such as modules and instances have an updateable __dict__ attribute; however, other objects may have write restrictions on their __dict__ attributes (for example, new-style classes use a dictproxy to prevent direct dictionary updates).
|
||||
|
||||
Without an argument, vars() acts like locals(). Note, the locals dictionary is only useful for reads since updates to the locals dictionary are ignored.
|
||||
|
||||
===== xrange(stop) =====
|
||||
|
||||
===== xrange(start, stop[, step]) =====
|
||||
This function is very similar to range(), but returns an xrange object instead of a list. This is an opaque sequence type which yields the same values as the corresponding list, without actually storing them all simultaneously. The advantage of xrange() over range() is minimal (since xrange() still has to create the values when asked for them) except when a very large range is used on a memory-starved machine or when all of the range’s elements are never used (such as when the loop is usually terminated with break). For more information on xrange objects, see XRange Type and Sequence Types — str, unicode, list, tuple, bytearray, buffer, xrange.
|
||||
|
||||
CPython implementation detail: xrange() is intended to be simple and fast. Implementations may impose restrictions to achieve this. The C implementation of Python restricts all arguments to native C longs (“short” Python integers), and also requires that the number of elements fit in a native C long. If a larger range is needed, an alternate version can be crafted using the itertools module: islice(count(start, step), (stop-start+step-1+2*(step<0))//step).
|
||||
|
||||
===== zip([iterable, ...]) =====
|
||||
This function returns a list of tuples, where the i-th tuple contains the i-th element from each of the argument sequences or iterables. The returned list is truncated in length to the length of the shortest argument sequence. When there are multiple arguments which are all of the same length, zip() is similar to map() with an initial argument of None. With a single sequence argument, it returns a list of 1-tuples. With no arguments, it returns an empty list.
|
||||
|
||||
The left-to-right evaluation order of the iterables is guaranteed. This makes possible an idiom for clustering a data series into n-length groups using zip(*[iter(s)]*n).
|
||||
|
||||
zip() in conjunction with the * operator can be used to unzip a list:
|
||||
|
||||
>>>
|
||||
>>> x = [1, 2, 3]
|
||||
>>> y = [4, 5, 6]
|
||||
>>> zipped = zip(x, y)
|
||||
>>> zipped
|
||||
[(1, 4), (2, 5), (3, 6)]
|
||||
>>> x2, y2 = zip(*zipped)
|
||||
>>> x == list(x2) and y == list(y2)
|
||||
True
|
||||
New in version 2.0.
|
||||
|
||||
Changed in version 2.4: Formerly, zip() required at least one argument and zip() raised a TypeError instead of returning an empty list.
|
||||
|
||||
===== __import__(name[, globals[, locals[, fromlist[, level]]]]) =====
|
||||
Note This is an advanced function that is not needed in everyday Python programming, unlike importlib.import_module().
|
||||
This function is invoked by the import statement. It can be replaced (by importing the __builtin__ module and assigning to __builtin__.__import__) in order to change semantics of the import statement, but nowadays it is usually simpler to use import hooks (see PEP 302). Direct use of __import__() is rare, except in cases where you want to import a module whose name is only known at runtime.
|
||||
|
||||
The function imports the module name, potentially using the given globals and locals to determine how to interpret the name in a package context. The fromlist gives the names of objects or submodules that should be imported from the module given by name. The standard implementation does not use its locals argument at all, and uses its globals only to determine the package context of the import statement.
|
||||
|
||||
level specifies whether to use absolute or relative imports. The default is -1 which indicates both absolute and relative imports will be attempted. 0 means only perform absolute imports. Positive values for level indicate the number of parent directories to search relative to the directory of the module calling __import__().
|
||||
|
||||
When the name variable is of the form package.module, normally, the top-level package (the name up till the first dot) is returned, not the module named by name. However, when a non-empty fromlist argument is given, the module named by name is returned.
|
||||
|
||||
For example, the statement import spam results in bytecode resembling the following code:
|
||||
|
||||
spam = __import__('spam', globals(), locals(), [], -1)
|
||||
The statement import spam.ham results in this call:
|
||||
|
||||
spam = __import__('spam.ham', globals(), locals(), [], -1)
|
||||
Note how __import__() returns the toplevel module here because this is the object that is bound to a name by the import statement.
|
||||
|
||||
On the other hand, the statement from spam.ham import eggs, sausage as saus results in
|
||||
|
||||
_temp = __import__('spam.ham', globals(), locals(), ['eggs', 'sausage'], -1)
|
||||
eggs = _temp.eggs
|
||||
saus = _temp.sausage
|
||||
Here, the spam.ham module is returned from __import__(). From this object, the names to import are retrieved and assigned to their respective names.
|
||||
|
||||
If you simply want to import a module (potentially within a package) by name, use importlib.import_module().
|
||||
|
||||
Changed in version 2.5: The level parameter was added.
|
||||
|
||||
Changed in version 2.5: Keyword support for parameters was added.
|
||||
|
||||
===== 3. Non-essential Built-in Functions =====
|
||||
There are several built-in functions that are no longer essential to learn, know or use in modern Python programming. They have been kept here to maintain backwards compatibility with programs written for older versions of Python.
|
||||
|
||||
Python programmers, trainers, students and book writers should feel free to bypass these functions without concerns about missing something important.
|
||||
|
||||
apply(function, args[, keywords])
|
||||
The function argument must be a callable object (a user-defined or built-in function or method, or a class object) and the args argument must be a sequence. The function is called with args as the argument list; the number of arguments is the length of the tuple. If the optional keywords argument is present, it must be a dictionary whose keys are strings. It specifies keyword arguments to be added to the end of the argument list. Calling apply() is different from just calling function(args), since in that case there is always exactly one argument. The use of apply() is equivalent to function(*args, **keywords).
|
||||
|
||||
Deprecated since version 2.3: Use function(*args, **keywords) instead of apply(function, args, keywords) (see Unpacking Argument Lists).
|
||||
|
||||
buffer(object[, offset[, size]])
|
||||
The object argument must be an object that supports the buffer call interface (such as strings, arrays, and buffers). A new buffer object will be created which references the object argument. The buffer object will be a slice from the beginning of object (or from the specified offset). The slice will extend to the end of object (or will have a length given by the size argument).
|
||||
|
||||
coerce(x, y)
|
||||
Return a tuple consisting of the two numeric arguments converted to a common type, using the same rules as used by arithmetic operations. If coercion is not possible, raise TypeError.
|
||||
|
||||
intern(string)
|
||||
Enter string in the table of “interned” strings and return the interned string – which is string itself or a copy. Interning strings is useful to gain a little performance on dictionary lookup – if the keys in a dictionary are interned, and the lookup key is interned, the key comparisons (after hashing) can be done by a pointer compare instead of a string compare. Normally, the names used in Python programs are automatically interned, and the dictionaries used to hold module, class or instance attributes have interned keys.
|
||||
|
||||
Changed in version 2.3: Interned strings are not immortal (like they used to be in Python 2.2 and before); you must keep a reference to the return value of intern() around to benefit from it.
|
||||
|
||||
Footnotes
|
||||
|
||||
[1] It is used relatively rarely so does not warrant being made into a statement.
|
||||
[2] Specifying a buffer size currently has no effect on systems that don’t have setvbuf(). The interface to specify the buffer size is not done using a method that calls setvbuf(), because that may dump core when called after any I/O has been performed, and there’s no reliable way to determine whether this is the case.
|
||||
[3] In the current implementation, local variable bindings cannot normally be affected this way, but variables retrieved from other scopes (such as modules) can be. This may change.
|
||||
»
|
||||
indexmodules |next |previous | Python » Documentation » The Python Standard Library »
|
||||
© Copyright 1990-2012, Python Software Foundation.
|
||||
The Python Software Foundation is a non-profit corporation. Please donate.
|
||||
Last updated on Dec 01, 2012. Found a bug?
|
||||
Created using Sphinx 1.0.7.
|
||||
@@ -0,0 +1,57 @@
|
||||
Content-Type: text/x-zim-wiki
|
||||
Wiki-Format: zim 0.4
|
||||
Creation-Date: 2012-12-02T20:49:44+08:00
|
||||
|
||||
====== 4. Built-in Constants ======
|
||||
Created Sunday 02 December 2012
|
||||
|
||||
A small number of constants live in the built-in namespace. They are:
|
||||
|
||||
===== False =====
|
||||
The false value of the bool type.
|
||||
|
||||
New in version 2.3.
|
||||
|
||||
===== True =====
|
||||
The true value of the bool type.
|
||||
|
||||
New in version 2.3.
|
||||
|
||||
===== None =====
|
||||
The sole value of types.NoneType. None is frequently used to represent the absence of a value, as when default arguments are not passed to a function.
|
||||
|
||||
Changed in version 2.4: Assignments to None are illegal and raise a SyntaxError.
|
||||
|
||||
===== NotImplemented =====
|
||||
Special value which can be returned by the “rich comparison” special methods (__eq__(), __lt__(), and friends), to indicate that the comparison is not implemented with respect to the other type.
|
||||
|
||||
===== Ellipsis =====
|
||||
Special value used in conjunction with extended slicing syntax.
|
||||
|
||||
===== __debug__ =====
|
||||
This constant is true if Python was __not started with an -O option__. See also the assert statement.
|
||||
|
||||
Note The names None and __debug__ cannot be reassigned (assignments to them, even as an attribute name, raise SyntaxError), so they can be considered “true” constants.
|
||||
Changed in version 2.7: Assignments to __debug__ as an attribute became illegal.
|
||||
|
||||
===== 4.1. Constants added by the site module =====
|
||||
The site module (which is __imported automatically during startup__, except if the -S command-line option is given) adds several constants to the built-in namespace. They are useful for the interactive interpreter shell and should not be used in programs.
|
||||
|
||||
===== quit([code=None]) =====
|
||||
|
||||
===== exit([code=None]) =====
|
||||
Objects that when printed, print a message like “Use quit() or Ctrl-D (i.e. EOF) to exit”, and when called, raise SystemExit with the specified exit code.
|
||||
|
||||
==== copyright ====
|
||||
|
||||
==== license ====
|
||||
|
||||
==== credits ====
|
||||
Objects that when printed, print a message like “Type license() to see the full license text”, and when called, display the corresponding text in a pager-like fashion (one screen at a time).
|
||||
|
||||
»
|
||||
indexmodules |next |previous | Python » Documentation » The Python Standard Library »
|
||||
© Copyright 1990-2012, Python Software Foundation.
|
||||
The Python Software Foundation is a non-profit corporation. Please donate.
|
||||
Last updated on Dec 02, 2012. Found a bug?
|
||||
Created using Sphinx 1.0.7.
|
||||
File diff suppressed because it is too large
Load Diff
38
Zim/Programme/python/The-Python-Standard-Library/int.txt
Normal file
38
Zim/Programme/python/The-Python-Standard-Library/int.txt
Normal file
@@ -0,0 +1,38 @@
|
||||
Content-Type: text/x-zim-wiki
|
||||
Wiki-Format: zim 0.4
|
||||
Creation-Date: 2012-12-02T10:31:10+08:00
|
||||
|
||||
====== int ======
|
||||
Created Sunday 02 December 2012
|
||||
|
||||
|
||||
In [12]: lst = '123\n' //如果字符串中包含__空字符(如空格, \t, \v, \f, \n, \r)等__,int(), float()等函数仍然有效。
|
||||
In [13]: lst
|
||||
Out[13]: '123\n'
|
||||
|
||||
__In [14]: int(lst)__
|
||||
__Out[14]: 123__
|
||||
|
||||
In [15]: lst = '123\n\t'
|
||||
|
||||
In [16]: lst
|
||||
Out[16]: '123\n\t'
|
||||
|
||||
In [18]: int(lst)
|
||||
Out[18]: 123
|
||||
|
||||
|
||||
In [19]: lst = '123\nstr' //字符串中包含除了数字外的非空字符,转换时提示错误。
|
||||
|
||||
In [20]: lst
|
||||
Out[20]: '123\nstr'
|
||||
|
||||
In [21]: int(lst)
|
||||
---------------------------------------------------------------------------
|
||||
ValueError Traceback (most recent call last)
|
||||
<ipython-input-21-7fdf78d62dad> in <module>()
|
||||
----> 1 int(lst)
|
||||
|
||||
__ValueError:__ invalid literal for int() with **base 10**: '123\nstr'
|
||||
|
||||
In [22]:
|
||||
74
Zim/Programme/python/The-Python-Standard-Library/list.txt
Normal file
74
Zim/Programme/python/The-Python-Standard-Library/list.txt
Normal file
@@ -0,0 +1,74 @@
|
||||
Content-Type: text/x-zim-wiki
|
||||
Wiki-Format: zim 0.4
|
||||
Creation-Date: 2012-12-02T09:40:06+08:00
|
||||
|
||||
====== list ======
|
||||
Created Sunday 02 December 2012
|
||||
|
||||
~ $ ipython2
|
||||
Python 2.7.3 (default, Apr 24 2012, 00:06:13)
|
||||
Type "copyright", "credits" or "license" for more information.
|
||||
|
||||
In [1]: lst = ['sdfds', 'dsfsd', 1, 3, [123, 22, 33, 'dsfds']]
|
||||
|
||||
__In [2]: lst[0]=[1, 2, 3] //为列表的某个成员赋值时,python不会对右边的值进行迭代。__
|
||||
|
||||
In [3]: lst
|
||||
Out[3]: 1, 2, 3], 'dsfsd', 1, 3, [123, 22, 33, 'dsfds'
|
||||
|
||||
__In [8]: lst[0:0] = 'dffds' //为列表的成员列表赋值时,python会对右边的值进行迭代。__
|
||||
|
||||
In [9]: lst
|
||||
Out[9]: [__'d', 'f', 'f', 'd', 's',__ 'dffds', 2, 3, 'dsfsd', 1, 3, [123, 22, 33, 'dsfds']] //可见,python对等式右边序列进行了迭代。
|
||||
|
||||
In [4]: lst[0:1] = [1, 2, 3]
|
||||
|
||||
In [5]: lst
|
||||
Out[5]: [1, 2, 3, 'dsfsd', 1, 3, [123, 22, 33, 'dsfds']] //同上
|
||||
|
||||
In [10]:
|
||||
|
||||
__In [10]: lst[0:0] = ['dffds'] //将字符序列外加[和]就可以阻止迭代(因为这时字符串时列表的唯一成员)__
|
||||
|
||||
In [11]: lst
|
||||
Out[11]:
|
||||
['dffds',
|
||||
'd',
|
||||
'f',
|
||||
'f',
|
||||
'd',
|
||||
's',
|
||||
'dffds',
|
||||
2,
|
||||
3,
|
||||
'dsfsd',
|
||||
1,
|
||||
3,
|
||||
[123, 22, 33, 'dsfds']]
|
||||
|
||||
In [12]:
|
||||
|
||||
In [24]: lst
|
||||
Out[24]: '123\nstr'
|
||||
|
||||
In [25]: lst = [1, 2, 3]
|
||||
|
||||
In [26]: lst = lst + [4, 5, 6] //列表相+时,python会对第二个列表进行__迭代__。
|
||||
|
||||
In [27]: lst
|
||||
Out[27]: [1, 2, 3, **4, 5, 6]**
|
||||
|
||||
__In [28]: lst = lst + 'fdf' //只能list间相加__
|
||||
---------------------------------------------------------------------------
|
||||
TypeError Traceback (most recent call last)
|
||||
<ipython-input-28-0818686a3a7d> in <module>()
|
||||
----> 1 lst = lst + 'fdf'
|
||||
|
||||
TypeError: **can only concatenate list** (not "str") to list
|
||||
|
||||
In [29]: lst = lst + list('fdf')
|
||||
|
||||
In [30]: lst
|
||||
Out[30]: [1, 2, 3, 4, 5, 6, 'f', 'd', 'f']
|
||||
|
||||
In [31]:
|
||||
350
Zim/Programme/python/The-Python-Standard-Library/pexpect.txt
Normal file
350
Zim/Programme/python/The-Python-Standard-Library/pexpect.txt
Normal file
@@ -0,0 +1,350 @@
|
||||
Content-Type: text/x-zim-wiki
|
||||
Wiki-Format: zim 0.4
|
||||
Creation-Date: 2012-01-05T15:16:44+08:00
|
||||
|
||||
====== pexpect ======
|
||||
Created Thursday 05 January 2012
|
||||
http://www.noah.org/wiki/Pexpect
|
||||
|
||||
Contents
|
||||
|
||||
1 Pexpect version 2.3
|
||||
2 Description of Pexpect
|
||||
3 License
|
||||
4 Download and Installation
|
||||
5 Project Status
|
||||
6 Requirements for use of Pexpect
|
||||
6.1 Python
|
||||
6.2 pty module
|
||||
7 Source Code
|
||||
8 Examples
|
||||
8.1 topip.py
|
||||
8.2 hive.py
|
||||
8.3 script.py
|
||||
8.4 fix_cvs_files.py
|
||||
8.5 ftp.py
|
||||
8.6 monitor.py
|
||||
8.7 passmass.py
|
||||
8.8 python.py
|
||||
8.9 rippy.py
|
||||
8.10 sshls.py
|
||||
8.11 ssh_tunnel.py
|
||||
8.12 uptime.py
|
||||
9 API Documentation
|
||||
9.1 Core
|
||||
9.2 experimental extensions
|
||||
10 Overview
|
||||
11 Special EOF and TIMEOUT patterns
|
||||
12 Lists if patterns
|
||||
13 Find the end of line -- CR/LF conventions
|
||||
14 Beware of + and * at the end of input
|
||||
15 Matching groups
|
||||
16 Debugging
|
||||
17 Exceptions
|
||||
18 FAQ
|
||||
18.1 Q: Isn't there already a Python Expect?
|
||||
18.2 Q: The `before` and `after` properties sound weird.
|
||||
18.3 Q: Why not just use Expect?
|
||||
18.4 Q: Why not just use a pipe (popen())?
|
||||
18.5 Q: Can I do screen scraping with this thing?
|
||||
|
||||
===== Pexpect version 2.3 =====
|
||||
|
||||
Download the current version here from the SourceForge site here: pexpect current
|
||||
|
||||
===== Description of Pexpect =====
|
||||
|
||||
Pexpect is a **pure Python module** that makes Python a better tool for__ controlling and automating other programs__. Pexpect is similar to the Don Libes `Expect` system, but Pexpect as a different interface that is easier to understand.
|
||||
|
||||
Pexpect is__ basically a pattern matching system__. It runs programs and watches output. When output matches a given pattern Pexpect can **respond** as if a human were typing responses. Pexpect can be used for** automation, testing, and screen scraping**.
|
||||
|
||||
Pexpect can be used for__ automating interactive console applications __such as ssh, ftp, passwd, telnet, etc. It can also be used to__ control web applications__ via `lynx`, `w3m`, or some other **text-based **web browser. Pexpect is pure Python. Unlike other Expect-like modules for Python Pexpect does not require TCL or Expect nor does it require C extensions to be compiled. It should work on any platform that supports the standard Python __pty__ module.
|
||||
|
||||
Send questions to: noah@noah.org Put 'pexpect' in the subject.
|
||||
|
||||
===== Download and Installation =====
|
||||
|
||||
Download the current version here from the SourceForge site here: pexpect current
|
||||
|
||||
The Pexpect tarball is **a standard Python Distutil distribution**. Running the following commands should get you a working Pexpect module. Note that you have to have root access to install a site package.
|
||||
|
||||
wget http://pexpect.sourceforge.net/pexpect-2.3.tar.gz
|
||||
tar xzf pexpect-2.3.tar.gz
|
||||
cd pexpect-2.3
|
||||
sudo python ./setup.py install
|
||||
|
||||
===== Project Status =====
|
||||
|
||||
Automated __pyunit tests__ reach over 80% code coverage on pexpect.py. I regularly test on Linux and BSD platforms. I try to test on Solaris and Irix.
|
||||
|
||||
===== Requirements for use of Pexpect =====
|
||||
* **Python**
|
||||
Pexpect was written and tested with Python 2.5. It should work on earlier versions that have the pty module. I sometimes even manually test it with Python 1.5.2, but I can't easily run the PyUnit test framework against Python 1.5.2.
|
||||
* **pty module**
|
||||
Any POSIX system (UNIX) with a working pty module should be able to run Pexpect. The pty module is part of the Standard Python Library, so if you are running on a POSIX system you should have it. The pty module does not run the same on all platforms. It should be solid on Linux and BSD systems. I have taken effort to try to smooth the wrinkles out of the different platforms. To learn more about the wrinkles see Bugs and Testing.
|
||||
|
||||
Pexpect does **not currently work on the standard Windows Python** (see the pty requirement); however, it seems to work fine using Cygwin. It is possible to build something like a pty for Windows, but it would have to use a different technique that I am still investigating. I know it's possible because Libes' Expect was ported to Windows. If you have any ideas or skills to contribute in this area then I would really appreciate some tips on how to approach this problem.
|
||||
|
||||
===== Source Code =====
|
||||
|
||||
You can browse the source code in SVN online here: SVN trunk
|
||||
Note that all PyUnit tests are under the tests/ directory. To run the unit tests you will need to source the test.env environment file:
|
||||
|
||||
source test.env
|
||||
|
||||
then you will need to run the testall.py script under the tools/ directory:
|
||||
|
||||
tools/testall.py
|
||||
|
||||
===== Examples =====
|
||||
|
||||
Under the distribution tarball directory you should find an "examples" directory.__ This is the best way to learn to use Pexpect__. See the descriptions of Pexpect Examples.
|
||||
* topip.py
|
||||
|
||||
This runs `netstat` on a local or remote server. It **calculates some simple statistical information** on the number of external inet connections. This can be used to detect if one IP address is taking up an excessive number of connections. It can also send an email alert if a given IP address exceeds a threshold between runs of the script. This script can be used as a drop-in Munin plugin or it can be used stand-alone from cron. I used this on a busy web server that would sometimes get hit with denial of service attacks. This made it easy to see if a script was opening many multiple connections. A typical browser would open fewer than 10 connections at once. A script might open over 100 simultaneous connections.
|
||||
* hive.py
|
||||
|
||||
This script creates SSH connections to a list of hosts that you provide. Then you are given a command line prompt. Each shell command that you enter is** sent to all the hosts**. The response from each host is collected and printed. For example, you could connect to a dozen different machines and reboot them all at once.
|
||||
* script.py
|
||||
|
||||
This implements a command similar to the classic BSD "script" command. This will start a subshell and log all input and output to a file. This demonstrates the interact() method of Pexpect.
|
||||
* fix_cvs_files.py
|
||||
|
||||
This is for cleaning up binary files improperly added to CVS. This script scans the given path to find binary files; checks with CVS to see if the sticky options are set to -kb; finally if sticky options are not -kb then uses 'cvs admin' to set the -kb option.
|
||||
* ftp.py
|
||||
|
||||
This demonstrates an FTP "bookmark". This connects to an ftp site; does a few ftp tasks; and then gives the user interactive control over the session. In this case the "bookmark" is to a directory on the OpenBSD ftp server. It puts you in the i386 packages directory. You can easily modify this for other sites. This demonstrates the interact() method of Pexpect.
|
||||
* monitor.py
|
||||
|
||||
This runs a sequence of commands on a remote host using SSH. It runs a simple system checks such as uptime and free to monitor the state of the remote host.
|
||||
* passmass.py
|
||||
|
||||
This will login to each given server and change the password of the given user. This demonstrates scripting logins and passwords.
|
||||
* python.py
|
||||
|
||||
This starts the python interpreter and prints the greeting message backwards. It then gives the user iteractive control of Python. It's pretty useless!
|
||||
* rippy.py
|
||||
|
||||
This is a wizard for mencoder. It greatly simplifies the process of ripping a DVD to Divx (mpeg4) format. It can transcode from any video file to another. It has options for resampling the audio stream; removing interlace artifacts, fitting to a target file size, etc. There are lots of options, but the process is simple and easy to use.
|
||||
* sshls.py
|
||||
|
||||
This lists a directory on a remote machine.
|
||||
* ssh_tunnel.py
|
||||
|
||||
This starts an SSH tunnel to a remote machine. It monitors the connection and restarts the tunnel if it goes down.
|
||||
* uptime.py
|
||||
|
||||
This will run the uptime command and parse the output into variables. This demonstrates using a single regular expression to match the output of a command and capturing different variable in match groups. The grouping regular expression handles a wide variety of different uptime formats.
|
||||
|
||||
===== API Documentation =====
|
||||
|
||||
==== Core ====
|
||||
**pexpect **- This is the main module that you want.
|
||||
**pxssh** - Pexpect SSH is an extension of 'pexpect.spawn' that specializes in SSH.
|
||||
|
||||
==== experimental extensions ====
|
||||
fdpexpect - fdpexpect extension of 'pexpect.spawn' that uses an open file descriptor. You can pass it __any file descriptor__ and use pexpect commands to match output from your fd.
|
||||
screen - This represents a virtual 'screen'.
|
||||
ANSI - This parses ANSI/VT-100 terminal escape codes.
|
||||
FSM - This is a finite state machine used by ANSI.
|
||||
|
||||
===== Overview =====
|
||||
Pexpect can be used for __automating interactive applications__ such as ssh, ftp, mencoder, passwd, etc. The Pexpect interface was designed to be easy to use. Here is an example of Pexpect in action:
|
||||
|
||||
# This connects to the openbsd ftp site and
|
||||
# downloads the recursive directory listing.
|
||||
import pexpect
|
||||
child = pexpect.spawn ('ftp ftp.openbsd.org')
|
||||
child.__expect__ ('Name .*: ')
|
||||
child.__sendline__ ('anonymous')
|
||||
child.expect ('Password:')
|
||||
child.sendline ('noah@example.com')
|
||||
child.expect ('ftp> ')
|
||||
child.sendline ('cd pub')
|
||||
child.expect('ftp> ')
|
||||
child.sendline ('get ls-lR.gz')
|
||||
child.expect('ftp> ')
|
||||
child.sendline ('bye')
|
||||
|
||||
Obviously you could write an ftp client using Python's own ftplib module, but this is just a demonstration. You can use this technique with any application. This is especially handy if you are writing **automated test tools**.
|
||||
|
||||
There are two important methods in Pexpect --__ expect()__ and __send()__ (or __sendline()__ which is like send() with a linefeed). The expect() method waits for the child application to** return a given string**. The string you specify is a __regular expression__, so you can match complicated patterns. The send() method writes a string to the child application. From the child's point of view it looks just like someone **typed the text from a terminal**. After each call to expect() the __before and after properties__ will be set to the text printed by child application. The before property will contain all text up to the expected string pattern. The after string will contain the text that was **matched **by the expected pattern. The __match property__ is set to the re MatchObject.
|
||||
|
||||
An example of Pexpect in action may make things more clear. This example uses ftp to login to the OpenBSD site; list files in a directory; and then pass interactive control of the ftp session to the human user.
|
||||
|
||||
import pexpect
|
||||
child = pexpect.spawn ('ftp ftp.openbsd.org')
|
||||
child.expect ('Name .*: ')
|
||||
child.sendline ('anonymous')
|
||||
child.expect ('Password:')
|
||||
child.sendline ('noah@example.com')
|
||||
child.expect ('ftp> ')
|
||||
child.sendline ('ls /pub/OpenBSD/')
|
||||
child.expect ('ftp> ')
|
||||
__print child.before__ # Print the result of the ls command.#打印上个expect匹配前输出的内容。
|
||||
__child.interact() __ # Give control of the child to the user.
|
||||
|
||||
===== Special EOF and TIMEOUT patterns =====
|
||||
|
||||
There are two special patterns to match the End Of File or a Timeout condition. You you can pass these patterns to expect(). These patterns are not regular expressions. Use them like __predefined constants__.
|
||||
|
||||
If the child has **died** and you have read all the child's output then ordinarily expect() will raise an **EOF exception**. You can read everything up to the EOF without generating an exception by using the EOF pattern __expect(pexpect.EOF)__. In this case everything the child has output will be available in the **before property**.
|
||||
|
||||
===== Lists if patterns =====
|
||||
|
||||
The pattern given to expect() may be __a regular expression__ or it may also be __a list of regular expressions__. This allows you to__ match multiple optional responses__. The expect() method returns the** index** of the pattern that was matched. For example, say you wanted to login to a server. After entering a password you could get various responses from the server -- your password could be rejected; or you could be allowed in and asked for your terminal type; or you could be let right in and given a command prompt. The following code fragment gives an example of this:
|
||||
|
||||
child.expect('password:')
|
||||
child.sendline (my_secret_password)
|
||||
# We expect any of these three patterns...
|
||||
i = child.expect** (['Permission denied', 'Terminal type', '[#\$] '])**
|
||||
if i==0:
|
||||
print 'Permission denied on host. Can't login'
|
||||
__child.kill(0)__
|
||||
elif i==2:
|
||||
print 'Login OK... need to send terminal type.'
|
||||
child.sendline('vt100')
|
||||
child.expect ('[#\$] ')
|
||||
elif i==3:
|
||||
print 'Login OK.'
|
||||
print 'Shell command prompt', __child.after__
|
||||
|
||||
If nothing matches an expected pattern then__ expect will eventually raise a TIMEOUT exception__. The default time is 30 seconds, but you can change this by passing a t**imeout argument** to expect():
|
||||
|
||||
# Wait no more than 2 minutes (120 seconds) for password prompt.
|
||||
child.expect('password:', __timeout=120__)
|
||||
|
||||
===== Find the end of line -- CR/LF conventions =====
|
||||
|
||||
Matching at the __end of a line__ can be tricky. In general **the $ regex pattern is useless**. Pexpect matches regular expressions a little differently than what you might be used to. The $ matches the end of string, but Pexpect reads from the child **one character at a time**, so each character looks like the end of a line. Pexpect can't do a look-ahead into the child's output stream. In general you would have this situation when using regular expressions with a stream. Note, pexpect does have an internal buffer, so reads are faster than one character at a time, but from the user's perspective the regex pattern test happens one character at a time.
|
||||
|
||||
The best way to match the end of a line is to **look for the **__newline__**: "\r\n" (CR/LF)**. Yes, that does appear to be DOS-style. It may surprise some UNIX people to learn that **terminal TTY device drivers** (dumb, vt100, ANSI, xterm, etc.) all use the CR/LF combination to mark the end of line. **UNIX uses just linefeeds to end lines in **__files__**, but not when it comes to TTY devices**!
|
||||
|
||||
Pexpect uses a__ Pseudo-TTY__ device to talk to the child application, so when the child application prints a "\n" your TTY device actually sees "\r\n". TTY devices are more like the Windows world. Each line of text end with a CR/LF combination. When you intercept data from a UNIX command from a TTY device you will find that the TTY device outputs a CR/LF combination.
|
||||
|
||||
**A UNIX command may** only write a linefeed (\n), __but the TTY device driver converts it to CR/LF__. This means that your terminal will see lines end with CR/LF (hex 0D 0A). Since **Pexpect emulates a terminal**, to match ends of lines you have to expect the CR/LF combination.
|
||||
|
||||
child.expect__ ('\r\n')__
|
||||
|
||||
If you just need to skip past a new line then expect ('\n') by itself will work, but if you are expecting a specific pattern before the end of line then you need to explicitly look for the \r. For example the following **expects a word at the end of a line**:
|
||||
|
||||
__ child.expect ('\w+\r\n')__
|
||||
|
||||
But the following would both fail:
|
||||
|
||||
child.expect ('\w+\n')
|
||||
|
||||
And as explained before, trying to use '$' to match the end of line would not work either:
|
||||
|
||||
child.expect ('\w+$')
|
||||
|
||||
So if you need to explicitly look for the END OF LINE, you want to look for the __CR/LF combination__ -- not just the LF and not the $ pattern.
|
||||
|
||||
This problem is not limited to Pexpect. **This problem happens any time you try to perform a regular expression match on a stream.** Regular expressions need to look ahead. **With a stream it is hard to look ahead** because the process generating the stream may not be finished. There is no way to know if the process has paused momentarily or is finished and waiting for you.
|
||||
|
||||
Pexpect must implicitly always do a NON greedy match (minimal) at the end of a input {### already said this}.
|
||||
|
||||
Pexpect compiles all regular expressions with the __DOTALL __flag. With the DOTALL flag a "." will match a newline.
|
||||
|
||||
===== Beware of + and * at the end of input =====
|
||||
|
||||
Remember that any time you try to match a pattern that needs look-ahead that __you will always get a minimal match (non greedy)__. For example, the following will always return just one character:
|
||||
|
||||
child.expect ('.+')
|
||||
|
||||
This example will match successfully, but will always return no characters:
|
||||
|
||||
child.expect ('.*')
|
||||
|
||||
Generally any star * expression will **match as little as possible.**
|
||||
|
||||
One thing you can do is to try to force a non-ambiguous character at the end of your \d+ pattern. Expect that character to delimit the string. For example, you might try making thr end of your pattrn be \D+ instead of \D*. That means number digits alone would not satisfy the (\d+) pattern. You would need some number(s) and at least one \D at the end.
|
||||
|
||||
===== Matching groups =====
|
||||
|
||||
You can group regular expression using **parenthesis**. After a match, the __match parameter__ of the spawn object will contain the Python re.match object.
|
||||
|
||||
===== Debugging =====
|
||||
|
||||
If you get the __string value__ of a pexpect.spawn object you will get lots of useful debugging information. For debugging it's very useful to use the following pattern:
|
||||
|
||||
try:
|
||||
|
||||
i = child.expect ([pattern1, pattern2, pattern3, etc])
|
||||
|
||||
except:
|
||||
|
||||
print "Exception was thrown"
|
||||
print "debug information:"
|
||||
print__ str__(child)
|
||||
|
||||
It is also useful to__ log the child's input and out to a file or the screen__. The following will turn on logging and send output to stdout (the screen).
|
||||
|
||||
child = pexpect.spawn (foo)
|
||||
child.logfile = sys.stdout
|
||||
|
||||
===== Exceptions =====
|
||||
|
||||
* EOF
|
||||
|
||||
Note that two flavors of EOF Exception may be thrown. They are virtually identical except for the message string. For practical purposes you should have no need to distinguish between them, but they do give a little extra information about what type of platform you are running. The two messages are:
|
||||
|
||||
End Of File (EOF) in read(). Exception style platform.
|
||||
End Of File (EOF) in read(). Empty string style platform.
|
||||
|
||||
Some UNIX platforms will throw an exception when you try to read from a file descriptor in the EOF state. Other UNIX platforms instead quietly return an empty string to indicate that the EOF state has been reached.
|
||||
|
||||
Expecting EOF
|
||||
|
||||
If you wish to read up to the end of the child's output **without generating an EOF exception** then use the __expect(pexpect.EOF)__ method.
|
||||
|
||||
* TIMEOUT
|
||||
|
||||
The expect() and read() methods will also timeout if the child does not generate any output for a given amount of time. If this happens they will raise a TIMEOUT exception. You can have these method ignore a timeout and block indefinitely by passing None for the timeout parameter.
|
||||
|
||||
child.expect(pexpect.EOF, timeout=None)
|
||||
|
||||
===== FAQ =====
|
||||
Q: Isn't there already a Python Expect?
|
||||
|
||||
A: Yes, there are several of them. They usually require you to compile C. I wanted something that was pure Python and preferably a single module that was simple to install. I also wanted something that was easy to use. This pure Python expect only recently became possible with the introduction of the** pty module** in the standard Python library. Previously C extensions were required.
|
||||
Q: The `before` and `after` properties sound weird.
|
||||
|
||||
A:__ This is how the -B and -A options in grep works__, so that made it easier for me to remember. Whatever makes my life easier is what's best. Originally I was going to model Pexpect after Expect, but then I found that I didn't actually like the way Expect did some things. It was more confusing. The `after` property can be a little confusing at first, because** it will actually include the matched string**. __The `after` means after the point of match, not after the matched string.__
|
||||
Q: Why not just use Expect?
|
||||
|
||||
A: I love it. It's great. I has bailed me out of some real jams, but I wanted something that would do 90% of what I need from Expect; be 10% of the size; and allow me to write my code in Python instead of TCL. Pexpect is not nearly as big as Expect, but Pexpect does everything I have ever used Expect for.
|
||||
Q: Why not just use a pipe (popen())?
|
||||
|
||||
A: **A pipe works fine for getting the output to**__ non-interactive__** programs**. If you just want to get the output from ls, uname, or ping then this works. Pipes do not work very well for interactive programs and pipes will almost certainly fail for most applications that ask for passwords such as telnet, ftp, or ssh.
|
||||
|
||||
There are two reasons for this.
|
||||
|
||||
===== First =====
|
||||
an application may **bypass stdout** and__ print directly to its controlling TTY__. Something like SSH will do this when it asks you for a password. This is why you cannot redirect the password prompt because it does not go through stdout or stderr.
|
||||
|
||||
===== second =====
|
||||
reason is because most applications are built using the **C Standard IO Library** (anything that uses #include <stdio.h>). One of the features of the stdio library is that __it buffers all input and output.__ Normally output is** line buffered** when a program is printing to a TTY (your terminal screen). Everytime the program prints a line-feed the currently buffered data will get printed to your screen. The problem comes when you connect a __pipe__. The stdio library is smart and can tell that it is printing to a pipe instead of a TTY. In that case it switches from line buffer mode to __block buffered__. In this mode the currently buffered data is flushed when the__ buffer is full__. This causes most interactive programs to __deadlock__. Block buffering is more efficient when writing to disks and pipes. Take the situation where a program prints a message "Enter your user name:\n" and then waits for you type type something. In block buffered mode, __the stdio library will not put the message into the pipe __even though a linefeed is printed. The result is that you never receive the message, yet the child application will sit and wait for you to type a response. Don't confuse the stdio lib's buffer with the pipe's buffer. The pipe buffer is another area that can cause problems. You could flush the input side of a pipe, whereas you have __no control over the stdio library__ buffer.
|
||||
|
||||
===== More information =====
|
||||
: the Standard IO library has three states for a FILE *. These are: _IOFBF for block buffered; _IOLBF for line buffered; and _IONBF for unbuffered. The STDIO lib will use block buffering when talking to a **block file descriptor** such as a pipe. This is usually not helpful for interactive programs. Short of recompiling your program to include __fflush() __everywhere or recompiling a custom stdio library there is not much a controlling application can do about this if talking over a pipe.
|
||||
|
||||
The program may have put data in its output that remains unflushed because the output buffer is not full; then the program will go and deadlock while waiting for input -- because you never send it any because you are still waiting for its output (still stuck in the STDIO's output buffer).
|
||||
|
||||
The answer is to use a
|
||||
|
||||
===== pseudo-tty =====
|
||||
. A TTY device will force line buffering (as opposed to block buffering). Line buffering means that you will get each line when the child program sends a line feed. This corresponds to the way most interactive programs operate -- send a line of output then wait for a line of input.
|
||||
|
||||
I put "answer" in quotes because it's ugly solution and because there is no POSIX standard for pseudo-TTY devices (even though they have a TTY standard...). What would make more sense to me would be to have some way to __set a mode on a file descriptor __so that it will tell the STDIO to be line-buffered. I have investigated, and I don't think there is a way to set the buffered state of a child process. The STDIO Library does not maintain any external state in the kernel or whatnot, so I don't think there is any way for you to alter it. I'm not quite sure how this line-buffered/block-buffered state change happens internally in the STDIO library. I think the STDIO lib looks at the file descriptor and decides to change behavior based on whether it's a TTY or a block file (see isatty()).
|
||||
|
||||
I hope that this qualifies as helpful. __Don't use a pipe to control another application__...
|
||||
|
||||
Pexpect may seem similar to **os.popen()** or commands module. The main difference is that__ Pexpect (like Expect) uses a pseudo-TTY to talk to the child__ __application__.
|
||||
|
||||
Most applications do no work well through the system() call or through pipes. And probably all applications that ask a user to type in a password will fail. These applications bypass the stdin and read directly from the TTY device. Many applications do not explicitly flush their output buffers. This causes deadlocks if you try to control an interactive application using a pipe. What happens is that most UNIX applications use the stdio (#include <stdio.h>) for input and output. The stdio library behaves differently depending on where the output is going. There is no way to control this behavior from the client end.
|
||||
Q: Can I do screen scraping with this thing?
|
||||
|
||||
A: That depends. If your application just does line-oriented output then this is easy. If it does screen-oriented output then it may work, but it could be hard. For example, trying to scrape data from the 'top' command would be hard. The top command repaints the text window.
|
||||
|
||||
I am working on an ANSI / VT100 terminal emulator that will have methods to get characters from an arbitrary X,Y coordinate of the virtual screen. It works and you can play with it, but I have no working examples at this time.
|
||||
1045
Zim/Programme/python/The-Python-Standard-Library/re.txt
Normal file
1045
Zim/Programme/python/The-Python-Standard-Library/re.txt
Normal file
File diff suppressed because it is too large
Load Diff
@@ -0,0 +1,92 @@
|
||||
Content-Type: text/x-zim-wiki
|
||||
Wiki-Format: zim 0.4
|
||||
Creation-Date: 2012-11-30T20:55:38+08:00
|
||||
|
||||
====== string的操作函数 ======
|
||||
Created Friday 30 November 2012
|
||||
|
||||
转自:http://www.91linux.com/html/article/program/python/20090804/17759.htm
|
||||
|
||||
在python有各种各样的string操作函数。在历史上string类在python中经历了一段轮回的历史。在最开始的时候,python有**一个专门的string的module**,要使用string的方法要先import,但后来由于众多的python使用者的建议,从python2.0开始,string方法改为用S.method()的形式调用,只要S是一个字符串对象就可以这样使用,而不用import。同时__为了保持向后兼容__,现在的python中仍然保留了一个string的module,其中定义的方法与S.method()是相同的,这些方法都**最后都指向了**用S.method()调用的函数。要注意,S.method()能调用的方法比string的module中的多,比如isdigit()、istitle()等就只能用S.method()的方式调用。
|
||||
|
||||
对一个字符串对象,首先想到的操作可能就是计算它有多少个字符组成,很容易想到用S.len(),但这是错的,应该是__len(S)__。因为len()是内置函数,包括在__builtin__模块中。python不把len()包含在string类型中,乍看起来好像有点不可理解,其实一切有其合理的逻辑在里头。len()不仅可以计算字符串中的字符数,还可以计算list的成员数,tuple的成员数等等,因此**单单把len()算在string里是不合适**,因此一是可以__把len()作为通用函数__,用重载实现对不同类型的操作,还有就是可以在每种有len()运算的类型中都要包含一个len()函数。python选择的是第一种解决办法。类似的还有str(arg)函数,它把arg用string类型表示出来。
|
||||
|
||||
===== 字符串中字符大小写的变换: =====
|
||||
S.lower() #小写
|
||||
S.upper() #大写
|
||||
S.swapcase() #大小写互换
|
||||
S.capitalize() #首字母大写
|
||||
String.capwords(S)
|
||||
#这是模块中的方法。它把S用split()函数分开,然后用capitalize()把首字母变成大写,最后用join()合并到一起
|
||||
S.title() #只有首字母大写,其余为小写,模块中没有这个方法
|
||||
|
||||
===== 字符串在输出时的对齐: =====
|
||||
S.ljust(width,[fillchar])
|
||||
#输出width个字符,S左对齐,不足部分用fillchar填充,默认的为空格。
|
||||
S.rjust(width,[fillchar]) #右对齐
|
||||
S.center(width, [fillchar]) #中间对齐
|
||||
S.zfill(width) #把S变成width长,并在右对齐,不足部分用0补足
|
||||
|
||||
===== 字符串中的搜索和替换: =====
|
||||
S.find(substr, [start, [end]])
|
||||
#返回S中出现substr的第一个字母的标号,如果S中没有substr则返回-1。start和end作用就相当于在S[start:end]中搜索
|
||||
S.index(substr, [start, [end]])
|
||||
#与find()相同,只是在S中没有substr时,会返回一个运行时错误
|
||||
S.rfind(substr, [start, [end]])
|
||||
#返回S中最后出现的substr的第一个字母的标号,如果S中没有substr则返回-1,也就是说从右边算起的第一次出现的substr的首字母标号
|
||||
S.rindex(substr, [start, [end]])
|
||||
S.count(substr, [start, [end]]) #计算substr在S中出现的次数
|
||||
S.replace(oldstr, newstr, [count])
|
||||
#把S中的oldstar替换为newstr,count为替换次数。这是替换的通用形式,还有一些函数进行特殊字符的替换
|
||||
S.strip([chars])
|
||||
#把S中前后chars中有的字符全部去掉,可以理解为把S前后chars替换为None
|
||||
S.lstrip([chars])
|
||||
S.rstrip([chars])
|
||||
S.expandtabs([tabsize])
|
||||
#把S中的tab字符替换没空格,每个tab替换为tabsize个空格,默认是8个
|
||||
|
||||
===== 字符串的分割和组合: =====
|
||||
S.split([sep, [maxsplit]])
|
||||
#以sep为分隔符,把S分成一个list。maxsplit表示分割的次数。默认的分割符为空白字符
|
||||
S.rsplit([sep, [maxsplit]])
|
||||
S.splitlines([keepends])
|
||||
#把S按照行分割符分为一个list,keepends是一个bool值,如果为真每行后而会保留行分割符。
|
||||
S.join(seq) #把seq代表的序列──字符串序列,用S连接起来
|
||||
|
||||
|
||||
|
||||
===== 字符串的mapping,这一功能包含两个函数: =====
|
||||
String.maketrans(from, to)
|
||||
#返回一个256个字符组成的翻译表,其中from中的字符被一一对应地转换成to,所以from和to必须是等长的。
|
||||
S.translate(table[,deletechars])
|
||||
#使用上面的函数产后的翻译表,把S进行翻译,并把deletechars中有的字符删掉。需要注意的是,如果S为unicode字符串,那么就不支持deletechars参数,可以使用把某个字符翻译为None的方式实现相同的功能。此外还可以使用codecs模块的功能来创建更加功能强大的翻译表。
|
||||
|
||||
===== 字符串还有一对编码和解码的函数: =====
|
||||
S.encode([encoding,[errors]])
|
||||
#其中encoding可以有多种值,比如gb2312 gbk gb18030 bz2 zlib big5 bzse64等都支持。errors默认值为"strict",意思是UnicodeError。可能的值还有'ignore', 'replace', 'xmlcharrefreplace', 'backslashreplace' 和所有的通过codecs.register_error注册的值。这一部分内容涉及codecs模块,不是特明白
|
||||
|
||||
S.decode([encoding,[errors]])
|
||||
|
||||
===== 字符串的测试函数,这一类函数在string模块中没有,这些函数返回的都是bool值: =====
|
||||
|
||||
S.startwith(prefix[,start[,end]])
|
||||
#是否以prefix开头
|
||||
S.endwith(suffix[,start[,end]])
|
||||
#以suffix结尾
|
||||
S.isalnum()
|
||||
#是否全是字母和数字,并至少有一个字符
|
||||
S.isalpha() #是否全是字母,并至少有一个字符
|
||||
S.isdigit() #是否全是数字,并至少有一个字符
|
||||
S.isspace() #是否全是空白字符,并至少有一个字符
|
||||
S.islower() #S中的字母是否全是小写
|
||||
S.isupper() #S中的字母是否便是大写
|
||||
S.istitle() #S是否是首字母大写的
|
||||
|
||||
===== 字符串类型转换函数,这几个函数只在string模块中有: =====
|
||||
|
||||
**string.atoi(s[,base])**
|
||||
#base默认为10,如果为0,那么s就可以是012或0x23这种形式的字符串,如果是16那么s就只能是0x23或0X12这种形式的字符串
|
||||
string.atol(s[,base]) #转成long
|
||||
string.atof(s[,base]) #转成float
|
||||
|
||||
这里再强调一次,字符串对象是不可改变的,也就是说在python创建一个字符串后,你不能把这个字符中的某一部分改变。任何上面的函数改变了字符串后,都会返回一个__新的字符串__,原字串并没有变。其实这也是有变通的办法的,__可以用S=list(S)这个函数把S变为由单个字符为成员的list,这样的话就可以使用S[3]='a'的方式改变值,然后再使用S=" ".join(S)还原成字符串__
|
||||
501
Zim/Programme/python/The-Python-Standard-Library/subprocess.txt
Normal file
501
Zim/Programme/python/The-Python-Standard-Library/subprocess.txt
Normal file
@@ -0,0 +1,501 @@
|
||||
Content-Type: text/x-zim-wiki
|
||||
Wiki-Format: zim 0.4
|
||||
Creation-Date: 2012-01-05T16:23:46+08:00
|
||||
|
||||
====== subprocess ======
|
||||
Created Thursday 05 January 2012
|
||||
|
||||
===== 17.1. subprocess — Subprocess management =====
|
||||
|
||||
New in version 2.4.
|
||||
|
||||
The subprocess module allows you to__ spawn__ new processes, connect to their__ input/output/error pipes__, and obtain their __return codes__. This module intends to **replace** several other, older modules and functions, such as:
|
||||
|
||||
* os.system
|
||||
* os.spawn*
|
||||
* os.popen*
|
||||
* popen2.*
|
||||
* commands.*
|
||||
subprocess是推荐的执行shell命令或子进程的方式。
|
||||
|
||||
Information about how the subprocess module can be used to replace these modules and functions can be found in the following sections.
|
||||
|
||||
See also: PEP 324 – PEP proposing the subprocess module
|
||||
|
||||
===== 17.1.1. Using the subprocess Module =====
|
||||
|
||||
The recommended approach to invoking subprocesses is to use the following convenience functions for all use cases they can handle. For more advanced use cases, the underlying __Popen__ interface can be used directly.
|
||||
|
||||
三个模块函数:
|
||||
* subprocess.__call__(**args**, *, stdin=None, stdout=None, stderr=None, shell=False)
|
||||
* subprocess.__check_call__(args, *, stdin=None, stdout=None, stderr=None, shell=False)
|
||||
* subprocess.__check_output__(args, *, stdin=None, stderr=None, shell=False, **universal_newlines**=False)
|
||||
|
||||
两个模块变量:
|
||||
__subprocess.PIPE__
|
||||
__subprocess.STDOUT__
|
||||
|
||||
在功能能满足的情况下,尽量使用上面的三个函数,更复杂的交互式控制可以使用subprocess中提供的__Popen()类__。前两个函数返回命令的退出码,最后一个命令返回命令的输出为字符串。
|
||||
|
||||
[*] subprocess.__call__(**args**, *, stdin=None, stdout=None, stderr=None, shell=False)
|
||||
Run the command described by __args__. __Wait __for command to complete, then return the **returncode** attribute.
|
||||
适合非交互式进程,执行args指定的程序直到其结束,返回退出码,即使命令执行失败,也不产生异常。stdin,stdout,stderr一般不使用PIPE,因为调用进程一般不读这种非交互式进程的输出。stdin为None表示子进程的stdin将__继承__调用进程的描述符。
|
||||
|
||||
The arguments shown above are merely the most common ones, described below in Frequently Used Arguments (hence the slightly odd notation in the abbreviated signature). The full function signature is the same as that of the __Popen__ constructor - this functions passes all supplied arguments directly through to that interface.
|
||||
|
||||
Examples:
|
||||
>>>
|
||||
__#如果shell=False(默认),则python调用os.exelp()来执行args,因此,如果args是字符串,则只能包含命令名;如果是序列,则可以包含命令参数(参数不支持shell的特性如文件名扩展等。)。__
|
||||
>>> subprocess.call(__["ls", "-l"]__)
|
||||
0
|
||||
__#如果shell=True,则python调用system shell来执行args,调用形式为: execlp("/bin/sh", '-c', 'arg1', 'arg2', ....)因此,如果args是字符串,则其中可以包含命令参数,而且支持各种shell特性如文件名扩展、命令扩展等;如果args是序列,则其第一个元素为命令名,其它元素为被当作shell本身的参数。__
|
||||
|
||||
>>> subprocess.call("exit 1", shell=True)
|
||||
1
|
||||
|
||||
__总的来说__**:**如果shell=False, python使用os.execvp(...)来执行args,因此,如果args是一个string,则该string__只能是__命令名称, 如果要为命令附加参数,则只能使用序列类型; 如果shell=True,则python使用shell来执行行args,因此,args最好是一个string,该string可以包含命令名及其参数,如果使用序列,则从第二个元素开始作为shell本身的参数(而非命令的参数。)。
|
||||
|
||||
Invoking the system shell with shell=True can be **a security hazard** if combined with untrusted input. See the warning under Frequently Used Arguments for details.
|
||||
|
||||
__Do not use stdout=PIPE or stderr=PIPE with this function__. As the pipes are not being read in the current process, the child process may block if it generates enough output to a pipe to fill up the OS pipe buffer.
|
||||
当使用stdout=PIPE时,如果子进程填满了管道而调用进程没有读该管道时__子进程就会被阻塞__。因此使用上面三个函数时一般不使用这个参数。
|
||||
|
||||
The standard input and output channels for the process started by call() are__ bound to the parent’s input and output__. That means the calling programm __cannot capture the output__ of the command. Use check_output() to capture the output for later processing.
|
||||
|
||||
[*] subprocess.**check_call**(args, *, stdin=None, stdout=None, stderr=None, shell=False)
|
||||
和call类似,但是对返回值进行检查,如果非0则引发异常。
|
||||
|
||||
Run command with arguments. Wait for command to complete. **If the return code was zero then return**, otherwise raise__ CalledProcessError__. The CalledProcessError object will have the **return code **in the **returncode** attribute.
|
||||
|
||||
T Examples:
|
||||
>>>
|
||||
>>> subprocess.check_call(["ls", "-l"])
|
||||
0
|
||||
>>> subprocess.check_call("exit 1", shell=True)
|
||||
Traceback (most recent call last):
|
||||
...
|
||||
subprocess.CalledProcessError: Command 'exit 1' returned non-zero exit status 1
|
||||
|
||||
Note
|
||||
Do not use stdout=PIPE or stderr=PIPE with this function. As the pipes are not being read in the current process, the child process may block if it generates enough output to a pipe to fill up the OS pipe buffer.
|
||||
|
||||
[*] subprocess.__check_output__(args, *, stdin=None, stderr=None, shell=False, **universal_newlines**=False)
|
||||
执行命令,返回命令的输出为一字符串。如果命令执行失败,则产生异常。
|
||||
|
||||
Run command with arguments and return its output as a__ byte string__.
|
||||
If the return code was non-zero it raises a CalledProcessError. The CalledProcessError object will have the return code in the returncode attribute and any output in the output attribute.
|
||||
|
||||
Examples:
|
||||
>>>
|
||||
>>> subprocess.check_output(["echo", "Hello World!"])
|
||||
'Hello World!\n'
|
||||
>>> subprocess.check_output("exit 1", shell=True)
|
||||
Traceback (most recent call last):
|
||||
...
|
||||
subprocess.CalledProcessError: Command 'exit 1' returned non-zero exit status 1
|
||||
|
||||
To also capture standard error in the result, use__ stderr=subprocess.STDOUT__:
|
||||
>>>
|
||||
|
||||
>>> subprocess.check_output(
|
||||
... "ls non_existent_file; exit 0",
|
||||
... stderr=subprocess.STDOUT,
|
||||
... shell=True)
|
||||
'ls: non_existent_file: No such file or directory\n'
|
||||
|
||||
Note
|
||||
Do not use stderr=PIPE with this function. As the pipe is not being read in the current process, the child process may block if it generates enough output to the pipe to fill up the OS pipe buffer.
|
||||
|
||||
__subprocess.PIPE__
|
||||
Special value that can be used as the** stdin, stdout or stderr** argument to Popen and indicates that a pipe to the standard stream should be opened.
|
||||
如果stdin=PIPE, 则Popen(...)返回的Popen型对象的stdin属性返回一__写打开的文件对象__,向此文件写入的内容将会被传给子进程。stdout, stderr类似。
|
||||
|
||||
__subprocess.STDOUT__
|
||||
Special value that can be used as the **stderr** argument to Popen and indicates that standard error should go into the same handle as standard output.
|
||||
表示子进程的stderr被重定向**其stdout对应的文件中**。
|
||||
|
||||
=== 17.1.1.1. Frequently Used Arguments ===
|
||||
|
||||
To support a wide variety of use cases, the __Popen constructor__ (and the convenience functions) accept a large number of optional arguments. For most typical use cases, many of these arguments can be safely left at their default values. The arguments that are most commonly needed are:
|
||||
|
||||
* args is required for all calls and should be **a **__string__**, or a **__sequence__** of program arguments**. Providing a sequence of arguments is generally preferred, as it allows the module to take care of any required escaping and quoting of arguments (e.g. to permit spaces in file names). If passing a single string, either __shell must be True__ (see below) or else the string must simply name the program to be executed __without__ specifying any arguments.
|
||||
使用序列形式是首选的方式,这时一般将shell=False,python直接调用os.execlp()。这样可以避免shell代码注入风险。
|
||||
|
||||
* stdin, stdout and stderr specify the __executed program’s __standard input, standard output and standard error **file handles**, respectively. Valid values are__ PIPE, an existing file descriptor (a positive integer), an existing file object, and None__. PIPE indicates that a new pipe to the child should be created. With the default settings of None, no** redirection** will occur; the child’s file handles will be inherited from the parent. Additionally, stderr can be STDOUT, which indicates that the stderr data from the child process should be captured into **the same file** handle as for stdout.
|
||||
|
||||
When stdout or stderr are pipes and universal_newlines is True then all line endings will be converted to__ '\n'__ as described for the universal newlines ‘U’` mode argument to open().
|
||||
|
||||
* If shell is True, the specified command will be** executed through the shell**. This can be useful if you are using Python primarily for the enhanced control flow it offers over most system shells and still want __access to other shell features__ such as **filename wildcards, shell pipes and environment variable expansion**.
|
||||
使用shell时,args的字符串形式是首选的方式。
|
||||
|
||||
Warning
|
||||
Executing shell commands that incorporate unsanitized input from an untrusted source makes a program vulnerable to shell injection, a serious security flaw which can result in arbitrary command execution. For this reason, the use of __shell=True is strongly discouraged__ in cases where the command string is constructed from external input:
|
||||
>>>
|
||||
|
||||
>>> from subprocess import call
|
||||
>>> filename = input("What file would you like to display?\n")
|
||||
What file would you like to display?
|
||||
non_existent; rm -rf / #
|
||||
>>> call("cat " + filename, shell=True) # Uh-oh. This will end badly...
|
||||
|
||||
shell=False disables all shell based features, but does not suffer from this vulnerability; see the Note in the Popen constructor documentation for helpful hints in getting shell=False to work.
|
||||
|
||||
These options, along with all of the other options, are described in more detail in the Popen constructor documentation.
|
||||
|
||||
==== 17.1.1.2. Popen Constructor ====
|
||||
|
||||
subprocess模块中只定义了一个类:Popen
|
||||
|
||||
The **underlying** process creation and management in this module is handled by the__ Popen__ class. It offers a lot of flexibility so that developers are able to handle the less common cases not covered by the convenience functions.
|
||||
|
||||
__class subprocess.Popen__(args, bufsize=0, **executable**=None, stdin=None, stdout=None, stderr=None, preexec_fn=None, close_fds=False, shell=False, cwd=None, env=None, universal_newlines=False, startupinfo=None, creationflags=0)
|
||||
|
||||
Arguments are:
|
||||
|
||||
* args should be a string, or a sequence of program arguments. The program to execute is normally the **first item** in the args sequence or the string(string作为命令名,不能有参数) if a string is given, but can be **explicitly set **by using the __executable__ argument. When executable is given, the first item in the args sequence is still treated by most programs as the** command name**, which can then be different from the actual executable name. On Unix, it becomes the** display name** for the executing program in utilities such as ps. 如果ecutable被设置,则其值将作为__实际执行__的命令名。args的第一个元素将作为命令的显示名称。
|
||||
|
||||
On Unix, with shell=False (default): In this case, the __Popen class uses os.execvp()__ to execute the child program. args should **normally be a sequence.** If a string is specified for args, it will be used as the **name or path of the program **to execute; this will only work if the program is being given __no__ arguments.
|
||||
默认情况下shell=False,这样args通常为sequence,其第一个元素为待执行的命令,其它元素为命令参数。如果args为string,则其**只能为命令名或命令路径,不能带任何参数**。这时因为python使用os.execvp()来执行这个string。
|
||||
|
||||
Note
|
||||
|
||||
__shlex.split()__ can be useful when determining the correct tokenization for args, especially in complex cases:
|
||||
>>>
|
||||
|
||||
>>> import shlex, subprocess
|
||||
>>> command_line = raw_input()
|
||||
/bin/vikings -input eggs.txt -output "spam spam.txt" -cmd "echo '$MONEY'"
|
||||
>>> args = shlex.split(command_line)
|
||||
>>> print args
|
||||
['/bin/vikings', '-input', 'eggs.txt', '-output', 'spam spam.txt', '-cmd', "echo '$MONEY'"]
|
||||
>>> p = subprocess.Popen(args) # Success!
|
||||
|
||||
Note in particular that options (such as -input) and arguments (such as eggs.txt) that are separated by whitespace in the shell go in **separate list elements**, while arguments that need quoting or backslash escaping when used in the shell (such as filenames containing spaces or the echo command shown above) are single list elements.
|
||||
|
||||
On Unix, with shell=True: __If args is a string, it specifies the command string to execute through the shell.__ This means that the string must be formatted exactly as it would be when typed at the shell prompt. This includes, for example, quoting or backslash escaping filenames with spaces in them. If args is a sequence, the first item specifies the command string, and any additional items will be treated as additional arguments __to the shell itself__. That is to say, Popen does the equivalent of:
|
||||
在shell=True的情况下,args**最好是一个字符串**。如果是序列,则从第二个元素开始是__作为shell本身的参数__,而非命令的参数。
|
||||
__ Popen(['/bin/sh', '-c', args[0], args[1], ...])__
|
||||
|
||||
On Windows: the Popen class uses CreateProcess() to execute the child child program, which __operates on strings.__ If args is a sequence, it will be converted to a string in a manner described in Converting an argument sequence to a string on Windows.
|
||||
|
||||
**总的来说:如果shell=False, python使用os.execvp(...)来执行args,因此,如果args是一个string,则该string只能是命令名称, 如果要为命令执行参数,则只能使用序列类型; 如果shell=True,则python使用shell来执行行args,因此,args最好是一个string,该string可以包含命令名及其参数,如果使用序列,则从第二个元素开始作为**__shell本身__**的参数(而非命令的参数。)。**
|
||||
|
||||
* bufsize, if given, has the same meaning as the corresponding argument to the built-in open() function: **0 means **__unbuffered__**, 1 means**__ line buffered__**, any other positive value means use a buffer of (approximately) that size**. A negative bufsize means to use the system **default**, which usually means__ fully__ buffered. The** default value for bufsize is 0** __(unbuffered)__.
|
||||
控制打开文件的缓冲方式,默认为unbuffered。
|
||||
|
||||
Note
|
||||
If you experience performance issues, it is recommended that you try to enable buffering by setting bufsize to either -1 or a large enough positive value (such as 4096).
|
||||
|
||||
* The executable argument **specifies the program** to execute. It is very seldom needed: Usually, the program to execute is defined by the **args** argument. If shell=True, the executable argument specifies __which shell to use__. On Unix, the default shell is **/bin/sh**. On Windows, the default shell is specified by the COMSPEC environment variable. The only reason you would need to specify shell=True on Windows is where the command you wish to execute is actually built in to the shell, eg dir, copy. You don’t need shell=True to run a batch file, nor to run a console-based executable.
|
||||
|
||||
* stdin, stdout and stderr specify the __executed program’s __standard input, standard output and standard error file handles, respectively. Valid values are __PIPE, an existing file descriptor (a positive integer), an existing file object, and None__. PIPE indicates that a new pipe to the child should be created. With the **default settings of None**, no redirection will occur; the child’s file handles will be **inherited from the parent**. Additionally, stderr can be STDOUT, which indicates that the stderr data from the child process should be captured into the same file handle as for stdout.
|
||||
|
||||
* If__ preexec_fn__ is set to a callable object, this object will be called in the child process just **before** the child is executed. (Unix only)
|
||||
|
||||
* If close_fds is true,__ all file descriptors except 0, 1 and 2 will be closed__ before the child process is executed. (Unix only). Or, on Windows, if close_fds is true then no handles will be inherited by the child process. Note that on Windows, you cannot set close_fds to true and also redirect the standard handles by setting stdin, stdout or stderr.
|
||||
|
||||
* If shell is True, the specified command will be executed through the shell.
|
||||
|
||||
Warning
|
||||
Enabling this option can be a security hazard if combined with untrusted input. See the warning under Frequently Used Arguments for details.
|
||||
|
||||
* If cwd is not None, the child’s current directory will be changed to cwd **before **it is executed. Note that this directory is not considered when searching the executable, so you can’t specify the program’s path relative to cwd.
|
||||
|
||||
* If env is not None, it must be __a mapping__ that defines the environment variables for the new process; these are used instead of** inheriting** the current process’ environment, which is the default behavior.
|
||||
|
||||
Note
|
||||
If specified, __env must provide any variables__ required for the program to execute. On Windows, in order to run a side-by-side assembly the specified env must include a valid SystemRoot.
|
||||
|
||||
* If universal_newlines is True, the file objects stdout and stderr are __opened as text files__, but lines may be terminated by any of '\n', the Unix end-of-line convention, '\r', the old Macintosh convention or '\r\n', the Windows convention. All of these external representations are __seen as '\n' __by the Python program.
|
||||
|
||||
Note
|
||||
This feature is only available if Python is built with universal newline support (the default). Also, the newlines attribute of the file objects stdout, stdin and stderr are not updated by the communicate() method.
|
||||
|
||||
* If given, startupinfo will be a STARTUPINFO object, which is passed to the underlying __CreateProcess __function.
|
||||
* creationflags, if given, can be CREATE_NEW_CONSOLE or CREATE_NEW_PROCESS_GROUP. (Windows only)?
|
||||
|
||||
==== 17.1.1.3. Exceptions ====
|
||||
|
||||
Exceptions raised in the child process, before the new program has started to execute, will be__ re-raised in the parent__. Additionally, the exception object will have one extra attribute called **child_traceback**, which is a string containing traceback information from the child’s point of view.
|
||||
|
||||
The most common exception raised is __OSError__. This occurs, for example, when trying to execute a non-existent file. Applications should prepare for OSError exceptions.
|
||||
|
||||
A __ValueError __will be raised if Popen is called with invalid arguments.
|
||||
|
||||
check_call() and check_output() will raise__ CalledProcessError__ if the called process returns a** non-zero** return code.
|
||||
|
||||
==== 17.1.1.4. Security ====
|
||||
最好不要使用shell=True参数。
|
||||
Unlike some other popen functions, this implementation will **never call a system shell implicitly**. This means that all characters, including shell metacharacters, can __safely__ be passed to child processes. Obviously, if the shell is invoked explicitly, then it is the application’s responsibility to ensure that all whitespace and metacharacters are quoted appropriately.
|
||||
|
||||
==== 17.1.2. Popen Objects ====
|
||||
Popen()函数返回一个__Popen对象__。
|
||||
|
||||
Instances of the Popen class have the following methods:
|
||||
|
||||
**Popen.poll()**
|
||||
Check if child process __has terminated__. Set and return **returncode** attribute.
|
||||
|
||||
**Popen.wait()**
|
||||
|
||||
Wait for child process to terminate. Set and return **returncode** attribute.
|
||||
|
||||
Warning
|
||||
This will deadlock when using stdout=PIPE and/or stderr=PIPE and the child process generates enough output to a pipe such that it blocks waiting for the OS pipe buffer to accept more data. Use communicate() to avoid that.
|
||||
|
||||
__Popen.communicate__(input=None)
|
||||
|
||||
Interact with process: **Send data to stdin**. Read data from stdout and stderr, until __end-of-file__ is reached. Wait for process to terminate. The optional input argument should be __a string to be sent to the child process__, or None, if no data should be sent to the child.
|
||||
|
||||
communicate() returns __a tuple__ (stdoutdata, stderrdata).
|
||||
|
||||
Note that if you want to send data to the process’s stdin, you need to create the Popen object with__ stdin=PIPE__. Similarly, to get anything other than None in the result tuple, you need to give__ stdout=PIPE__ and/or __stderr=PIPE__ too.
|
||||
|
||||
Note
|
||||
The data read is buffered in memory, so do not use this method if the data size is large or unlimited.
|
||||
|
||||
**Popen.send_signal(signal)**
|
||||
|
||||
Sends the signal signal to the child.
|
||||
|
||||
Note
|
||||
On Windows, **SIGTERM **is an alias for terminate(). CTRL_C_EVENT and CTRL_BREAK_EVENT can be sent to processes started with a creationflags parameter which includes CREATE_NEW_PROCESS_GROUP.
|
||||
|
||||
|
||||
**Popen.terminate()**
|
||||
|
||||
Stop the child. On Posix OSs the method sends __SIGTERM__ to the child. On Windows the Win32 API function TerminateProcess() is called to stop the child.
|
||||
|
||||
**Popen.kill()**
|
||||
|
||||
Kills the child. On Posix OSs the function sends __SIGKILL__ to the child. On Windows kill() is an alias for terminate().
|
||||
|
||||
===== The following attributes are also available: =====
|
||||
**Popen对象**具有下列属性:
|
||||
Warning
|
||||
Use communicate() rather than //.stdin.write, .stdout.read or .stderr.read// to avoid deadlocks due to any of the other OS pipe buffers filling up and blocking the child process.
|
||||
|
||||
Popen.stdin #对Popen调用stdin属性,将返回一个**写打开的文件对象**。
|
||||
If the stdin argument was PIPE, this attribute is **a file object** that provides input to the child process. Otherwise, it is__ None__.
|
||||
|
||||
Popen.stdout
|
||||
If the stdout argument was PIPE, this attribute is a file object that provides output from the child process. Otherwise, it is None.
|
||||
|
||||
Popen.stderr
|
||||
If the stderr argument was PIPE, this attribute is a file object that provides error output from the child process. Otherwise, it is None.
|
||||
|
||||
Popen.__pid__
|
||||
The process ID of the child process. Note that if you set the shell argument to True, this is the process ID of the __spawned shell__.
|
||||
|
||||
Popen.__returncode__
|
||||
|
||||
The child return code, **set by poll() and wait()** (and indirectly by communicate()). A __None__ value indicates that the process hasn’t terminated yet. A negative value __-N__ indicates that the child was **terminated by signal N** (Unix only).
|
||||
|
||||
|
||||
===== 17.1.3.1. Constants =====
|
||||
|
||||
The subprocess module exposes the following constants.
|
||||
|
||||
subprocess.STD_INPUT_HANDLE
|
||||
The __standard input device__. Initially, this is the console input buffer, CONIN$.
|
||||
|
||||
subprocess.STD_OUTPUT_HANDLE
|
||||
The standard output device. Initially, this is the active console screen buffer, CONOUT$.
|
||||
|
||||
subprocess.STD_ERROR_HANDLE
|
||||
The standard error device. Initially, this is the active console screen buffer, CONOUT$.
|
||||
|
||||
subprocess.SW_HIDE
|
||||
Hides the window. Another window will be activated.
|
||||
|
||||
subprocess.STARTF_USESTDHANDLES
|
||||
Specifies that the STARTUPINFO.hStdInput, STARTUPINFO.hStdOutput, and STARTUPINFO.hStdError attributes contain additional information.
|
||||
|
||||
subprocess.STARTF_USESHOWWINDOW
|
||||
Specifies that the STARTUPINFO.wShowWindow attribute contains additional information.
|
||||
|
||||
subprocess.CREATE_NEW_CONSOLE
|
||||
|
||||
The new process ha**s a new console**, instead of inheriting its parent’s console __(the default)__.
|
||||
This flag is always set when Popen is created with shell=True.
|
||||
|
||||
subprocess.CREATE_NEW_PROCESS_GROUP
|
||||
|
||||
A Popen creationflags parameter to specify that __a new process group__ will be created. This flag is necessary for using __os.kill()__ on the subprocess.
|
||||
This flag is ignored if CREATE_NEW_CONSOLE is specified.
|
||||
|
||||
==== 17.1.4. Replacing Older Functions with the subprocess Module ====
|
||||
|
||||
In this section, “a becomes b” means that b can be used as a replacement for a.
|
||||
|
||||
Note
|
||||
All “a” functions in this section** fail (more or less) silently** if the executed program cannot be found; the “b” replacements raise__ OSError__ instead.
|
||||
In addition, the replacements using check_output() will fail with a __CalledProcessError__ if the requested operation produces a **non-zero** return code. The output is still available as the output attribute of the raised exception.
|
||||
如果子进程返回非0值,check_output将引发异常。
|
||||
|
||||
In the following examples, we assume that the relevant functions have already been imported from the subprocess module.
|
||||
|
||||
=== 17.1.4.1. Replacing /bin/sh shell backquote ===
|
||||
|
||||
output=`mycmd myarg`
|
||||
# becomes
|
||||
**output **= __check_output__(["mycmd", "myarg"])
|
||||
|
||||
=== 17.1.4.2. Replacing shell pipeline ===
|
||||
|
||||
output=`dmesg | grep hda`
|
||||
# becomes
|
||||
p1 = Popen(["dmesg"], __stdout=PIPE__)
|
||||
p2 = Popen(["grep", "hda"], stdin=__p1.stdout__, stdout=PIPE) #p1是Popen对象,其stdout返回一个读打开的文件对象(因为p1的stdout为PIPE)。
|
||||
__p1.stdout__.close() # Allow p1 to receive a SIGPIPE if p2 exits,**关键!!!**
|
||||
output = __p2.communicate()__[0] #communicate()返回一个__元组__,这里只取出第一个元素即子进程的标准输出。
|
||||
|
||||
The p1.stdout.close() call after starting the p2 is __important in order__ for p1 to receive a SIGPIPE if p2 exits before p1.
|
||||
具体解释如下:stackoverflow.com/q/7391689
|
||||
From Wikipedia, SIGPIPE is the signal sent to a process when it attempts to **write** to a pipe without a process connected to the other end.
|
||||
|
||||
When you first create p1 using **stdout=PIPE**, there is one process connected to the pipe, which is __your Python process__, and you can read the output using p1.stdout.
|
||||
最开始Popen()时,python解释器会连接到p1.stdout管道,这样在p2没有创建前,p1的cmd就可以执行了,输出将临时地放入管道中。
|
||||
When you create p2 using stdin=p1.stdout there are now __two processes__ connected to the pipe p1.stdout.
|
||||
|
||||
Generally when you are running processes in a pipeline you want **all processes** to end when any of the processes end. For this to happen automatically __you need to close p1.stdout so p2.stdin is the only process attached to that pipe__, this way if p2 ends and p1 writes additional data to stdout, it will receive a SIGPIPE since there are no longer any processes attached to that pipe.
|
||||
|
||||
Alternatively, for **trusted input**, the shell’s own pipeline support may still be used directly:
|
||||
|
||||
output=`dmesg | grep hda` # becomes output=__check_output__(“dmesg | grep hda”,__ shell=True__)
|
||||
|
||||
==== 17.1.4.3. Replacing os.system() ====
|
||||
|
||||
sts = os.system("mycmd" + " myarg") #os.system是**调用一个shell**来执行其参数对应的命令,返回的是子进程的退出值。
|
||||
# becomes
|
||||
sts =__ call__("mycmd" + " myarg",__ shell=True__) #返回子进程的退出值,即使为非0值时不会引发异常。
|
||||
|
||||
Notes:
|
||||
Calling the program through the shell is usually not required.
|
||||
A more realistic example would look like this:
|
||||
|
||||
try:
|
||||
**retcode** = call("mycmd" + " myarg", shell=True)
|
||||
if retcode < 0:
|
||||
print >>sys.stderr, "Child was terminated by signal", __-retcode__
|
||||
else:
|
||||
print >>sys.stderr, "Child returned", retcode
|
||||
__except OSError, e:__
|
||||
print **>>sys.stderr**, "Execution failed:", e
|
||||
|
||||
==== 17.1.4.4. Replacing the os.spawn family ====
|
||||
|
||||
P_NOWAIT example:
|
||||
|
||||
__pid__ = os.spawnlp(os.P_NOWAIT, "/bin/mycmd", "mycmd", "myarg")
|
||||
==>
|
||||
pid = Popen(["/bin/mycmd", "myarg"]).__pid__
|
||||
|
||||
P_WAIT example:
|
||||
|
||||
__retcode__ = os.spawnlp(os.P_WAIT, "/bin/mycmd", "mycmd", "myarg")
|
||||
==>
|
||||
retcode = call(["/bin/mycmd", "myarg"])
|
||||
|
||||
Vector example:
|
||||
|
||||
os.spawnvp(os.P_NOWAIT, path, args)
|
||||
==>
|
||||
Popen([path] + args[1:])
|
||||
|
||||
Environment example:
|
||||
|
||||
os.spawnlpe(os.P_NOWAIT, "/bin/mycmd", "mycmd", "myarg", env)
|
||||
==>
|
||||
Popen(["/bin/mycmd", "myarg"], **env**={"PATH": "/usr/bin"})
|
||||
|
||||
==== 17.1.4.5. Replacing os.popen(), os.popen2(), os.popen3() ====
|
||||
|
||||
pipe = os.popen("cmd", __'r'__, bufsize) #第二个参数指定管道打开的方式。
|
||||
==>
|
||||
pipe = Popen("cmd", shell=True, bufsize=bufsize, stdout=PIPE)__.stdout__
|
||||
|
||||
pipe = os.popen("cmd", 'w', bufsize)
|
||||
==>
|
||||
pipe = Popen("cmd", shell=True, bufsize=bufsize, stdin=PIPE)__.stdin__
|
||||
|
||||
(child_stdin, child_stdout) = os.popen2("cmd", mode, bufsize) #popen2同时返回与子进程相连的读、写__管道描述符__。
|
||||
==>
|
||||
p = Popen("cmd", shell=True, bufsize=bufsize,
|
||||
stdin=PIPE, stdout=PIPE, close_fds=True)
|
||||
(child_stdin, child_stdout) = (p.stdin, p.stdout) #返回与子进程相连的读、写__文件对象__。
|
||||
|
||||
(child_stdin,
|
||||
child_stdout,
|
||||
child_stderr) = os.popen3("cmd", mode, bufsize)
|
||||
==>
|
||||
p = Popen("cmd", shell=True, bufsize=bufsize,
|
||||
stdin=PIPE, stdout=PIPE, **stderr=PIPE**, close_fds=True)
|
||||
(child_stdin,
|
||||
child_stdout,
|
||||
child_stderr) = (p.stdin, p.stdout, p.stderr)
|
||||
|
||||
(child_stdin, child_stdout_and_stderr) = os.popen4("cmd", mode,
|
||||
bufsize)
|
||||
==>
|
||||
p = Popen("cmd", shell=True, bufsize=bufsize,
|
||||
stdin=PIPE, stdout=PIPE, __stderr=STDOUT__, close_fds=True) #STDOUT标示,子进程的标准出错和__它的__标准输出__重定向到同一个__文件。
|
||||
(child_stdin, child_stdout_and_stderr) = (p.stdin, p.stdout)
|
||||
|
||||
On Unix, os.popen2, os.popen3 and os.popen4 also accept __a sequence__ as the command to execute, in which case arguments will be passed **directly to the program** without shell intervention. This usage can be replaced as follows:
|
||||
|
||||
(child_stdin, child_stdout) = os.popen2(["/bin/ls", "-l"], mode,
|
||||
bufsize)
|
||||
==>
|
||||
p = Popen(["/bin/ls", "-l"], bufsize=bufsize, stdin=PIPE, stdout=PIPE)
|
||||
(child_stdin, child_stdout) = (p.stdin, p.stdout)
|
||||
|
||||
Return code handling translates as follows:
|
||||
|
||||
pipe = os.popen("cmd", 'w')
|
||||
...
|
||||
rc = pipe.close() //"cmd"进程读管道时收到EOF,程序一般将终止。
|
||||
if rc is not None and rc **>> 8**:
|
||||
print "There were some errors"
|
||||
==>
|
||||
process = Popen("cmd", 'w', shell=True, stdin=PIPE)
|
||||
...
|
||||
process.stdin.close() //**同样使'cmd'读到EOF**,而自动终止。
|
||||
if **process.wait()** != 0:
|
||||
print "There were some errors"
|
||||
|
||||
==== 17.1.4.6. Replacing functions from the popen2 module ====
|
||||
|
||||
(child_stdout, child_stdin) = popen2.popen2("somestring", bufsize, mode)
|
||||
==>
|
||||
p = Popen(["somestring"], shell=True, bufsize=bufsize,
|
||||
stdin=PIPE, stdout=PIPE, close_fds=True)
|
||||
(child_stdout, child_stdin) = (p.stdout, p.stdin)
|
||||
|
||||
On Unix, popen2 also accepts a sequence as the command to execute, in which case arguments will be passed directly to the program without shell intervention. This usage can be replaced as follows:
|
||||
|
||||
(child_stdout, child_stdin) = popen2.popen2(["mycmd", "myarg"], bufsize,
|
||||
mode)
|
||||
==>
|
||||
p = Popen(["mycmd", "myarg"], bufsize=bufsize,
|
||||
stdin=PIPE, stdout=PIPE, close_fds=True)
|
||||
(child_stdout, child_stdin) = (p.stdout, p.stdin)
|
||||
|
||||
popen2.Popen3 and popen2.Popen4 basically work as subprocess.Popen, except that:
|
||||
|
||||
* Popen raises an exception if the execution fails.
|
||||
* the capturestderr argument is replaced with the stderr argument.
|
||||
* stdin=PIPE and stdout=PIPE must be specified.
|
||||
* popen2 closes all file descriptors by default, but you have to specify close_fds=True with Popen.
|
||||
|
||||
===== 17.1.5. Notes =====
|
||||
17.1.5.1. Converting an argument sequence to a string on Windows
|
||||
|
||||
On Windows, an args sequence is converted to a string that can be parsed using the following rules (which correspond to the rules used by the MS C runtime):
|
||||
|
||||
* Arguments are delimited by white space, which is either a space or a tab.
|
||||
* A string surrounded by double quotation marks is interpreted as a single argument, regardless of white space contained within. A quoted string can be embedded in an argument.
|
||||
* A double quotation mark preceded by a backslash is interpreted as a literal double quotation mark.
|
||||
* Backslashes are interpreted literally, unless they immediately precede a double quotation mark.
|
||||
* If backslashes immediately precede a double quotation mark, every pair of backslashes is interpreted as a literal backslash. If the number of backslashes is odd, the last backslash escapes the next double quotation mark as described in rule 3.
|
||||
|
||||
@@ -0,0 +1,38 @@
|
||||
Content-Type: text/x-zim-wiki
|
||||
Wiki-Format: zim 0.4
|
||||
Creation-Date: 2012-01-05T22:29:27+08:00
|
||||
|
||||
====== Python Subprocess Module Examples ======
|
||||
Created Thursday 05 January 2012
|
||||
|
||||
http://www.moosechips.com/2010/07/python-subprocess-module-examples/
|
||||
|
||||
Some examples using the subprocess python module.
|
||||
|
||||
Make a system call three different ways:
|
||||
|
||||
#! /usr/bin/env python
|
||||
import subprocess
|
||||
# Use a sequence of args
|
||||
return_code = subprocess.call(["echo", "hello sequence"])
|
||||
|
||||
# Set shell=true so we can use a simple string for the command
|
||||
return_code = subprocess.call("echo hello string", shell=True)
|
||||
|
||||
# subprocess.call() is equivalent to using subprocess.Popen() and wait()
|
||||
proc = subprocess.Popen("echo hello popen", shell=True)
|
||||
return_code = proc.wait() # wait for process to finish so we can get the return code
|
||||
|
||||
Control stderr and stdout:
|
||||
|
||||
#! /usr/bin/env python
|
||||
import subprocess
|
||||
# Put stderr and stdout into pipes
|
||||
proc = subprocess.Popen("echo hello stdout; echo hello stderr >&2", \
|
||||
shell=True, stderr=subprocess.PIPE, stdout=subprocess.PIPE)
|
||||
return_code = proc.wait()
|
||||
# Read from pipes
|
||||
for line in proc.stdout:
|
||||
print("stdout: " + line.rstrip())
|
||||
for line in proc.stderr:
|
||||
print("stderr: " + line.rstrip())
|
||||
@@ -0,0 +1,566 @@
|
||||
Content-Type: text/x-zim-wiki
|
||||
Wiki-Format: zim 0.4
|
||||
Creation-Date: 2012-01-06T10:23:27+08:00
|
||||
|
||||
====== subprocess - New process module ======
|
||||
Created Friday 06 January 2012
|
||||
http://www.python.org/dev/peps/pep-0324/
|
||||
|
||||
PEP: 324
|
||||
Title: subprocess - New process module
|
||||
Version: 17a68e052d4f
|
||||
Last-Modified: 2007-06-19 04:20:07 +0000 (Tue, 19 Jun 2007)
|
||||
Author: Peter Astrand <astrand at lysator.liu.se>
|
||||
Status: Final
|
||||
Type: Standards Track
|
||||
Content-Type: text/plain
|
||||
Created: 19-Nov-2003
|
||||
Python-Version: 2.4
|
||||
Post-History:
|
||||
Abstract
|
||||
|
||||
This PEP describes a new module for starting and communicating
|
||||
with processes.
|
||||
|
||||
|
||||
|
||||
===== Motivation =====
|
||||
|
||||
Starting new processes is a common task in any programming
|
||||
language, and very common in a high-level language like Python.
|
||||
Good support for this task is needed, because:
|
||||
|
||||
- Inappropriate functions for starting processes could mean a
|
||||
security risk: If the program is __started through the shell__, and
|
||||
the arguments contain shell meta characters, the result can be
|
||||
disastrous. [1]
|
||||
因此,subprocess模块中的函数和类,默认是不使用shell的。
|
||||
|
||||
- It makes Python an even better replacement language for
|
||||
over-complicated shell scripts.
|
||||
subprocess中的Popen类,支持子进程与调用进程的PIPE连接。
|
||||
而且调用进程还可以使用信号等与子进程同步。
|
||||
|
||||
Currently, Python has a large number of different functions for
|
||||
process creation. This makes it hard for developers to choose.
|
||||
|
||||
The subprocess module provides the following __enhancements__ over
|
||||
previous functions:
|
||||
|
||||
- One "unified" module provides __all__ functionality from previous
|
||||
functions.
|
||||
|
||||
- __Cross-process exceptions__: Exceptions happening in the child
|
||||
before the new process has started to execute are re-raised in
|
||||
the parent. This means that it's easy to handle **exec()**
|
||||
** failures**, for example. With popen2, for example, it's
|
||||
impossible to detect if the execution failed.
|
||||
exec() failures会在调用进程中产生OSError异常,注意和子进程返回非0值的
|
||||
SubprocessError进行区分。
|
||||
|
||||
- __A hook__ for executing custom code between fork and exec. This
|
||||
can be used for, for example, changing uid.
|
||||
这个__非常有用__:如定义进程组,改变进程权限,重定向文件等。
|
||||
|
||||
- **No implicit **call of /bin/sh. This means that there is no need
|
||||
for escaping dangerous shell meta characters.
|
||||
|
||||
- All combinations of file descriptor redirection is possible.
|
||||
For example, the "python-dialog" [2] needs to spawn a process
|
||||
and redirect stderr, but not stdout. This is not possible with
|
||||
current functions, without using temporary files.
|
||||
子进程的stdin, stdout, stderr可以独立、任意的重定向。
|
||||
- With the subprocess module, it's possible to control if all open
|
||||
file descriptors __should be closed__ before the new program is
|
||||
executed.
|
||||
|
||||
- Support for __connecting several subprocesses__ (shell "pipe").
|
||||
|
||||
- Universal newline support.
|
||||
|
||||
- A __communicate()__ method, which makes it easy to send stdin data
|
||||
and read stdout and stderr data, without risking deadlocks.
|
||||
Most people are aware of the __flow control issues__ involved with
|
||||
child process communication, but not all have the patience or
|
||||
skills to write a fully correct and deadlock-free select loop.
|
||||
This means that many Python applications contain race
|
||||
conditions. A communicate() method in the standard library
|
||||
solves this problem.
|
||||
|
||||
|
||||
|
||||
===== Rationale =====
|
||||
|
||||
The following points summarizes the design:
|
||||
|
||||
- subprocess was based on popen2, which is tried-and-tested.
|
||||
|
||||
- The factory functions in popen2 have been removed, because I
|
||||
consider the class constructor equally easy to work with.
|
||||
|
||||
- popen2 contains several factory functions and classes for
|
||||
different combinations of redirection. subprocess, however,
|
||||
contains **one single class**. Since the subprocess module supports
|
||||
__12 different combinations__ of redirection, providing a class or
|
||||
function for each of them would be cumbersome and not very
|
||||
intuitive. Even with popen2, this is a readability problem.
|
||||
For example, many people cannot tell the difference between
|
||||
popen2.popen2 and popen2.popen4 without using the documentation.
|
||||
|
||||
- One small utility function is provided: __subprocess.call()__. It
|
||||
aims to be an enhancement over os.system(), while still very
|
||||
easy to use:
|
||||
|
||||
- It does not use the Standard C function system(), which has
|
||||
limitations.
|
||||
- It does not call the shell implicitly.
|
||||
- No need for quoting; using __an argument list__.
|
||||
- The return value is easier to work with.
|
||||
|
||||
The call() utility function accepts an 'args' argument, just
|
||||
like the__ Popen__ class constructor. It waits for the command to
|
||||
complete, then returns the **returncode** attribute. The
|
||||
implementation is very simple:
|
||||
|
||||
def call(*args, **kwargs):
|
||||
return __Popen(*args, **kwargs).wait()__
|
||||
|
||||
The motivation behind the call() function is simple: Starting a
|
||||
process and wait for it to finish is a common task.
|
||||
|
||||
While Popen supports a wide range of options, many users have
|
||||
simple needs. Many people are using os.system() today, mainly
|
||||
because it provides a simple interface. Consider this example:
|
||||
|
||||
os.system("stty sane -F " + device)
|
||||
|
||||
With subprocess.call(), this would look like:
|
||||
|
||||
subprocess.call(["stty", "sane", "-F", device])
|
||||
|
||||
or, if executing **through the shell**:
|
||||
|
||||
subprocess.call("stty sane -F " + device, shell=True)
|
||||
|
||||
- The __"preexec" __functionality makes it possible to run arbitrary
|
||||
code **between fork and exec**. One might ask why there are special
|
||||
arguments for setting the **environment** and **current directory**, but
|
||||
not for, for example, setting the uid. The answer is:
|
||||
|
||||
- Changing environment and working directory is considered
|
||||
fairly common.
|
||||
- Old functions like spawn() has support for an
|
||||
"env"-argument.
|
||||
- __env__ and __cwd__ are considered quite cross-platform: They make
|
||||
sense even on Windows.
|
||||
|
||||
- On POSIX platforms, no extension module is required: the module
|
||||
uses **os.fork(), os.execvp()** etc.
|
||||
|
||||
- On Windows platforms, the module requires either Mark Hammond's
|
||||
Windows extensions[5], or a small extension module called
|
||||
_subprocess.
|
||||
|
||||
|
||||
|
||||
===== Specification =====
|
||||
|
||||
This module defines__ one class called Popen__:
|
||||
|
||||
class Popen(args, bufsize=0, executable=None,
|
||||
stdin=None, stdout=None, stderr=None,
|
||||
preexec_fn=None, close_fds=False, shell=False,
|
||||
cwd=None, env=None, universal_newlines=False,
|
||||
startupinfo=None, creationflags=0):
|
||||
|
||||
|
||||
Arguments are:
|
||||
|
||||
- args should be __a string__, or__ a sequence__ of program arguments.
|
||||
The program to execute is normally the first item in the args
|
||||
sequence or string, but can be __explicitly set__ by using the
|
||||
executable argument.
|
||||
|
||||
On UNIX, with shell=False (default): In this case, the Popen
|
||||
class uses __os.execvp()__ to execute the child program. args
|
||||
should normally be a **sequence**. A string will be treated as a
|
||||
sequence with the string as the only item (the program to
|
||||
execute).
|
||||
|
||||
On UNIX, with shell=True: If args is a string, it specifies the
|
||||
__command string__ to execute through the shell. If args is a
|
||||
sequence, the first item specifies the command string, and any
|
||||
additional items will be treated as __additional shell arguments__.
|
||||
|
||||
On Windows: the Popen class uses CreateProcess() to execute the
|
||||
child program, which operates on strings. If args is a
|
||||
sequence, it will be converted to a string using the
|
||||
list2cmdline method. Please note that not all MS Windows
|
||||
applications interpret the command line the same way: The
|
||||
list2cmdline is designed for applications using the same rules
|
||||
as the MS C runtime.
|
||||
|
||||
- bufsize, if given, has the same meaning as the corresponding
|
||||
argument to the built-in open() function: 0 means __unbuffered__, 1
|
||||
means __line buffered__, any other positive value means use a buffer
|
||||
of (approximately) that size. A negative bufsize means to use
|
||||
the system default, which usually means __fully buffered__. The
|
||||
default value for bufsize is 0 (unbuffered).
|
||||
|
||||
- stdin, stdout and stderr specify the executed programs' standard
|
||||
input, standard output and standard error **file handles**,
|
||||
respectively. Valid values are__ PIPE__, an existing __file__
|
||||
__ descriptor__ (a positive integer), an existing __file object__, and
|
||||
__None__. PIPE indicates that a new pipe to the child should be
|
||||
created. With None, no redirection will occur; the child's file
|
||||
handles will be __inherited__ from the parent. Additionally, __stderr__
|
||||
__ can be STDOUT__, which indicates that the stderr data from the
|
||||
applications should be captured into the same file handle as for
|
||||
stdout.
|
||||
|
||||
- If preexec_fn is set to a__ callable object__, this object will be
|
||||
called in the child process just before the child is executed.
|
||||
|
||||
- If close_fds is true, all file descriptors except 0, 1 and 2
|
||||
will be closed before the child process is executed.
|
||||
|
||||
- If shell is true, the specified command will be executed through
|
||||
the shell.
|
||||
|
||||
- If cwd is not None, the current directory will be changed to cwd
|
||||
before the child is executed.
|
||||
|
||||
- If env is not None, it defines the environment variables for the
|
||||
new process.
|
||||
|
||||
- If** universal_newlines** is true, the file objects stdout and
|
||||
stderr are opened as a text file, but lines may be terminated
|
||||
by any of '\n', the Unix end-of-line convention, '\r', the
|
||||
Macintosh convention or '\r\n', the Windows convention. All of
|
||||
these external representations are seen as '\n' by the Python
|
||||
program. Note: This feature is only available if Python is
|
||||
built with universal newline support (the default). Also, the
|
||||
newlines attribute of the file objects stdout, stdin and stderr
|
||||
are not updated by the communicate() method.
|
||||
|
||||
- The startupinfo and creationflags, if given, will be passed to
|
||||
the underlying CreateProcess() function. They can specify
|
||||
things such as appearance of the main window and priority for
|
||||
the new process. (Windows only)
|
||||
|
||||
|
||||
This module also defines two shortcut functions:
|
||||
|
||||
- call(*args, **kwargs):
|
||||
Run command with arguments. Wait for command to complete,
|
||||
then return the returncode attribute.
|
||||
|
||||
The arguments are the same as for the Popen constructor.
|
||||
Example:
|
||||
|
||||
retcode = call(["ls", "-l"])
|
||||
|
||||
|
||||
===== Exceptions =====
|
||||
----------
|
||||
|
||||
Exceptions raised in the child process, before the new program has
|
||||
started to execute, will be__ re-raised__ in the parent.
|
||||
在fork之后,exec之前发生的异常(如exec执行失败)将在父进程中重新生成。
|
||||
Additionally, the exception object will have one extra attribute
|
||||
called '**child_traceback**', which is a string containing traceback
|
||||
information from the child's point of view.
|
||||
|
||||
The most common exception raised is __OSError__. This occurs, for
|
||||
example, when trying to execute a non-existent file. Applications
|
||||
should prepare for OSErrors.
|
||||
|
||||
A __ValueError__ will be raised if Popen is called with invalid
|
||||
arguments.
|
||||
|
||||
|
||||
===== Security =====
|
||||
--------
|
||||
|
||||
Unlike some other popen functions, this implementation will never
|
||||
call /bin/sh implicitly. This means that all characters,
|
||||
including shell meta-characters, can safely be passed to child
|
||||
processes.
|
||||
|
||||
|
||||
===== Popen objects =====
|
||||
-------------
|
||||
|
||||
Instances of the Popen class have the following methods:
|
||||
|
||||
poll()
|
||||
Check if child process has terminated. Returns** returncode**
|
||||
attribute.
|
||||
|
||||
wait()
|
||||
Wait for child process to terminate. Returns **returncode**
|
||||
attribute.
|
||||
|
||||
__communicate__(input=None)
|
||||
Interact with process: Send data to stdin. Read data from
|
||||
stdout and stderr, until end-of-file is reached. Wait for
|
||||
process to terminate. The optional stdin argument should be a
|
||||
string to be sent to the child process, or None, if no data
|
||||
should be sent to the child.
|
||||
|
||||
communicate() returns a tuple (stdout, stderr).
|
||||
|
||||
Note: The data read is buffered in memory, so do not use this
|
||||
method if the data size is large or unlimited.
|
||||
|
||||
The following attributes are also available:
|
||||
|
||||
__ stdin__
|
||||
If the stdin argument is PIPE, this attribute is a __file object__
|
||||
that provides input to the child process. Otherwise, it is
|
||||
None.
|
||||
|
||||
stdout
|
||||
If the stdout argument is PIPE, this attribute is a file
|
||||
object that provides output from the child process.
|
||||
Otherwise, it is None.
|
||||
|
||||
stderr
|
||||
If the stderr argument is PIPE, this attribute is file object
|
||||
that provides error output from the child process. Otherwise,
|
||||
it is None.
|
||||
|
||||
__ pid__
|
||||
The process ID of the child process.
|
||||
|
||||
__returncode__
|
||||
The child return code. A None value indicates that the
|
||||
process hasn't terminated yet. A negative value -N indicates
|
||||
that the child was terminated by__ signal N__ (UNIX only).
|
||||
|
||||
|
||||
|
||||
===== Replacing older functions with the subprocess module =====
|
||||
|
||||
In this section, "a ==> b" means that b can be used as a
|
||||
replacement for a.
|
||||
|
||||
Note: All functions in this section fail (more or less) silently
|
||||
if the executed program cannot be found; this module raises an
|
||||
OSError exception.
|
||||
|
||||
In the following examples, we assume that the subprocess module is
|
||||
imported with "from subprocess import *".
|
||||
|
||||
|
||||
Replacing /bin/sh shell backquote
|
||||
---------------------------------
|
||||
|
||||
output=`mycmd myarg`
|
||||
==>
|
||||
output = Popen(["mycmd", "myarg"], stdout=PIPE).communicate()[0]
|
||||
|
||||
|
||||
Replacing shell pipe line
|
||||
-------------------------
|
||||
|
||||
output=`dmesg | grep hda`
|
||||
==>
|
||||
p1 = Popen(["dmesg"], stdout=PIPE)
|
||||
p2 = Popen(["grep", "hda"], stdin=p1.stdout, stdout=PIPE)
|
||||
output = p2.communicate()[0]
|
||||
|
||||
|
||||
Replacing os.system()
|
||||
---------------------
|
||||
|
||||
sts = os.system("mycmd" + " myarg")
|
||||
==>
|
||||
p = Popen("mycmd" + " myarg", shell=True)
|
||||
sts = os.waitpid(p.pid, 0)
|
||||
|
||||
Note:
|
||||
|
||||
* Calling the program through the shell is usually not required.
|
||||
|
||||
* It's easier to look at the returncode attribute than the
|
||||
exit status.
|
||||
|
||||
A more real-world example would look like this:
|
||||
|
||||
try:
|
||||
retcode = call("mycmd" + " myarg", shell=True)
|
||||
if retcode < 0:
|
||||
print >>sys.stderr, "Child was terminated by signal", -retcode
|
||||
else:
|
||||
print >>sys.stderr, "Child returned", retcode
|
||||
except OSError, e:
|
||||
print >>sys.stderr, "Execution failed:", e
|
||||
|
||||
|
||||
Replacing os.spawn*
|
||||
-------------------
|
||||
|
||||
P_NOWAIT example:
|
||||
|
||||
pid = os.spawnlp(os.P_NOWAIT, "/bin/mycmd", "mycmd", "myarg")
|
||||
==>
|
||||
pid = Popen(["/bin/mycmd", "myarg"]).pid
|
||||
|
||||
|
||||
P_WAIT example:
|
||||
|
||||
retcode = os.spawnlp(os.P_WAIT, "/bin/mycmd", "mycmd", "myarg")
|
||||
==>
|
||||
retcode = call(["/bin/mycmd", "myarg"])
|
||||
|
||||
|
||||
Vector example:
|
||||
|
||||
os.spawnvp(os.P_NOWAIT, path, args)
|
||||
==>
|
||||
Popen([path] + args[1:])
|
||||
|
||||
|
||||
Environment example:
|
||||
|
||||
os.spawnlpe(os.P_NOWAIT, "/bin/mycmd", "mycmd", "myarg", env)
|
||||
==>
|
||||
Popen(["/bin/mycmd", "myarg"], env={"PATH": "/usr/bin"})
|
||||
|
||||
|
||||
Replacing os.popen*
|
||||
-------------------
|
||||
|
||||
pipe = os.popen(cmd, mode='r', bufsize)
|
||||
==>
|
||||
pipe = Popen(cmd, shell=True, bufsize=bufsize, stdout=PIPE).stdout
|
||||
|
||||
pipe = os.popen(cmd, mode='w', bufsize)
|
||||
==>
|
||||
pipe = Popen(cmd, shell=True, bufsize=bufsize, stdin=PIPE).stdin
|
||||
|
||||
|
||||
(child_stdin, child_stdout) = os.popen2(cmd, mode, bufsize)
|
||||
==>
|
||||
p = Popen(cmd, shell=True, bufsize=bufsize,
|
||||
stdin=PIPE, stdout=PIPE, close_fds=True)
|
||||
(child_stdin, child_stdout) = (p.stdin, p.stdout)
|
||||
|
||||
|
||||
(child_stdin,
|
||||
child_stdout,
|
||||
child_stderr) = os.popen3(cmd, mode, bufsize)
|
||||
==>
|
||||
p = Popen(cmd, shell=True, bufsize=bufsize,
|
||||
stdin=PIPE, stdout=PIPE, stderr=PIPE, close_fds=True)
|
||||
(child_stdin,
|
||||
child_stdout,
|
||||
child_stderr) = (p.stdin, p.stdout, p.stderr)
|
||||
|
||||
|
||||
(child_stdin, child_stdout_and_stderr) = os.popen4(cmd, mode, bufsize)
|
||||
==>
|
||||
p = Popen(cmd, shell=True, bufsize=bufsize,
|
||||
stdin=PIPE, stdout=PIPE, stderr=STDOUT, close_fds=True)
|
||||
(child_stdin, child_stdout_and_stderr) = (p.stdin, p.stdout)
|
||||
|
||||
|
||||
Replacing popen2.*
|
||||
------------------
|
||||
|
||||
Note: If the cmd argument to popen2 functions is a string, the
|
||||
command is executed through /bin/sh. If it is a list, the command
|
||||
is directly executed.
|
||||
|
||||
(child_stdout, child_stdin) = popen2.popen2("somestring", bufsize, mode)
|
||||
==>
|
||||
p = Popen(["somestring"], shell=True, bufsize=bufsize
|
||||
stdin=PIPE, stdout=PIPE, close_fds=True)
|
||||
(child_stdout, child_stdin) = (p.stdout, p.stdin)
|
||||
|
||||
|
||||
(child_stdout, child_stdin) = popen2.popen2(["mycmd", "myarg"], bufsize, mode)
|
||||
==>
|
||||
p = Popen(["mycmd", "myarg"], bufsize=bufsize,
|
||||
stdin=PIPE, stdout=PIPE, close_fds=True)
|
||||
(child_stdout, child_stdin) = (p.stdout, p.stdin)
|
||||
|
||||
The popen2.Popen3 and popen3.Popen4 basically works as
|
||||
subprocess.Popen, except that:
|
||||
|
||||
* subprocess.Popen raises an exception if the execution fails
|
||||
* the capturestderr argument is replaced with the stderr argument.
|
||||
* stdin=PIPE and stdout=PIPE must be specified.
|
||||
* popen2 closes all file descriptors by default, but you have to
|
||||
specify close_fds=True with subprocess.Popen.
|
||||
|
||||
|
||||
|
||||
Open Issues
|
||||
|
||||
Some features have been requested but is not yet implemented.
|
||||
This includes:
|
||||
|
||||
* Support for managing a whole flock of subprocesses
|
||||
|
||||
* Support for managing "daemon" processes
|
||||
|
||||
* Built-in method for killing subprocesses
|
||||
|
||||
While these are useful features, it's expected that these can be
|
||||
added later without problems.
|
||||
|
||||
* expect-like functionality, including pty support.
|
||||
|
||||
pty support is highly platform-dependent, which is a
|
||||
problem. Also, there are already other modules that provide this
|
||||
kind of functionality[6].
|
||||
|
||||
|
||||
|
||||
Backwards Compatibility
|
||||
|
||||
Since this is a new module, no major backward compatible issues
|
||||
are expected. The module name "subprocess" might collide with
|
||||
other, previous modules[3] with the same name, but the name
|
||||
"subprocess" seems to be the best suggested name so far. The
|
||||
first name of this module was "popen5", but this name was
|
||||
considered too unintuitive. For a while, the module was called
|
||||
"process", but this name is already used by Trent Mick's
|
||||
module[4].
|
||||
|
||||
The functions and modules that this new module is trying to
|
||||
replace (os.system, os.spawn*, os.popen*, popen2.*, commands.*)
|
||||
are expected to be available in future Python versions for a long
|
||||
time, to preserve backwards compatibility.
|
||||
|
||||
|
||||
|
||||
Reference Implementation
|
||||
|
||||
A reference implementation is available from
|
||||
http://www.lysator.liu.se/~astrand/popen5/.
|
||||
|
||||
|
||||
References
|
||||
|
||||
[1] Secure Programming for Linux and Unix HOWTO, section 8.3.
|
||||
http://www.dwheeler.com/secure-programs/
|
||||
|
||||
[2] Python Dialog
|
||||
http://pythondialog.sourceforge.net/
|
||||
|
||||
[3] http://www.iol.ie/~padraiga/libs/subProcess.py
|
||||
|
||||
[4] http://starship.python.net/crew/tmick/
|
||||
|
||||
[5] http://starship.python.net/crew/mhammond/win32/
|
||||
|
||||
[6] http://www.lysator.liu.se/~ceder/pcl-expect/
|
||||
|
||||
|
||||
Copyright
|
||||
|
||||
This document has been placed in the public domain.
|
||||
|
||||
@@ -0,0 +1,667 @@
|
||||
Content-Type: text/x-zim-wiki
|
||||
Wiki-Format: zim 0.4
|
||||
Creation-Date: 2012-01-05T21:07:10+08:00
|
||||
|
||||
====== subprocess – Work with additional processes ======
|
||||
Created Thursday 05 January 2012
|
||||
http://www.doughellmann.com/PyMOTW/subprocess/#module-subprocess
|
||||
Purpose: Spawn and communicate with additional processes.
|
||||
Available In: 2.4 and later
|
||||
|
||||
The subprocess module provides __a consistent interface__ to creating and working with additional processes. It offers a higher-level interface than some of the other available modules, and is intended to replace functions such as// os.system(), os.spawn*(), os.popen*(), popen2.*() and commands.*()//. To make it easier to compare subprocess with those other modules, many of the examples here re-create the ones used for// os and popen//.
|
||||
|
||||
The subprocess module defines one class,__ Popen__ and a few** wrapper functions** that use that class. The constructor for Popen takes arguments to set up the new process so the __parent can communicate with it via pipes__. It provides all of the functionality of the other modules and functions it replaces, and more. The API is consistent for all uses, and many of the extra steps of overhead needed (such as closing extra file descriptors and ensuring the pipes are closed) are “built in” instead of being handled by the application code separately.
|
||||
|
||||
Note
|
||||
The API is roughly the same, but the underlying implementation is slightly different between Unix and Windows. All of the examples shown here were tested on Mac OS X. Behavior on a non-Unix OS will vary.
|
||||
|
||||
===== Running External Command =====
|
||||
|
||||
To run an external command __without interacting with it__, such as one would do with os.system(), Use the call() function.
|
||||
|
||||
import subprocess
|
||||
|
||||
# Simple command
|
||||
[x] subprocess.call(['ls', '-1'], shell=True)
|
||||
上面的代码是错误的,因为在使用序列的情况下, shell应该为__False__.否则python调用一个shell来执行序列中的第一个命令,而将序列中的其它元素作为**shell本身**的参数。这也是下面的输出结果不是长格式的原因。
|
||||
|
||||
The command line arguments are passed as a list of strings, which avoids the need for escaping quotes or other special characters that might be interpreted by the shell.
|
||||
|
||||
$ python subprocess_os_system.py
|
||||
|
||||
__init__.py
|
||||
index.rst
|
||||
interaction.py
|
||||
repeater.py
|
||||
signal_child.py
|
||||
signal_parent.py
|
||||
subprocess_check_call.py
|
||||
subprocess_check_output.py
|
||||
subprocess_check_output_error.py
|
||||
subprocess_check_output_error_trap_output.py
|
||||
subprocess_os_system.py
|
||||
subprocess_pipes.py
|
||||
subprocess_popen2.py
|
||||
subprocess_popen3.py
|
||||
subprocess_popen4.py
|
||||
subprocess_popen_read.py
|
||||
subprocess_popen_write.py
|
||||
subprocess_shell_variables.py
|
||||
subprocess_signal_parent_shell.py
|
||||
subprocess_signal_setsid.py
|
||||
|
||||
Setting the__ shell__ argument to a true value causes subprocess to **spawn an intermediate shell process**, and tell it to run the command. The default is to run the command directly.
|
||||
|
||||
import subprocess
|
||||
|
||||
# Command with shell expansion
|
||||
subprocess.call('echo $HOME', shell=True) #由于是fork一个shell来执行args,因此参数字符串中可以包含__shell可以识别的各种特殊字符和语法__。
|
||||
|
||||
Using an intermediate shell means that variables, glob patterns, and other special shell features in the command string are processed before the command is run.
|
||||
|
||||
$ python subprocess_shell_variables.py
|
||||
|
||||
/Users/dhellmann
|
||||
|
||||
===== Error Handling =====
|
||||
|
||||
The return value from call() is the__ exit code__ of the program. The caller is responsible for interpreting it to detect errors. The** check_call()** function works like call() except that the__ exit code is checked__, and if it indicates an error happened then a **CalledProcessError** exception is raised.
|
||||
|
||||
import subprocess
|
||||
|
||||
subprocess.check_call(['false'])
|
||||
|
||||
The false command always exits with a non-zero status code, which check_call() interprets as an error.
|
||||
|
||||
$ python subprocess_check_call.py
|
||||
|
||||
Traceback (most recent call last):
|
||||
File "subprocess_check_call.py", line 11, in <module>
|
||||
subprocess.check_call(['false'])
|
||||
File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.
|
||||
7/subprocess.py", line 504, in check_call
|
||||
raise CalledProcessError(retcode, cmd)
|
||||
subprocess.CalledProcessError: Command '['false']' returned non-zero exit status 1
|
||||
|
||||
===== Capturing Output =====
|
||||
|
||||
The standard input and output channels for the process started by call() are__ bound to the parent’s input and output__. That means the **calling programm cannot capture the output of the command**. Use check_output() to capture the output for later processing.
|
||||
|
||||
import subprocess
|
||||
|
||||
__output__ = subprocess.check_output(['ls', '-1']) #捕获子进程的__标准输出__,并将其作为字符串返回。同时对命令的退出码进行检测,__若非0则产生异常,这时子进程被捕获的标准输出将被丢弃__。
|
||||
print 'Have %d bytes in output' % len(output)
|
||||
print output
|
||||
|
||||
|
||||
The ls -1 command runs successfully, so the text it prints to standard output is captured and returned.
|
||||
|
||||
$ python subprocess_check_output.py
|
||||
|
||||
Have 462 bytes in output
|
||||
__init__.py
|
||||
index.rst
|
||||
interaction.py
|
||||
repeater.py
|
||||
signal_child.py
|
||||
signal_parent.py
|
||||
subprocess_check_call.py
|
||||
subprocess_check_output.py
|
||||
subprocess_check_output_error.py
|
||||
subprocess_check_output_error_trap_output.py
|
||||
subprocess_os_system.py
|
||||
subprocess_pipes.py
|
||||
subprocess_popen2.py
|
||||
subprocess_popen3.py
|
||||
subprocess_popen4.py
|
||||
subprocess_popen_read.py
|
||||
subprocess_popen_write.py
|
||||
subprocess_shell_variables.py
|
||||
subprocess_signal_parent_shell.py
|
||||
subprocess_signal_setsid.py
|
||||
|
||||
This script runs a series of commands__ in a subshell__. Messages are sent to standard output and standard error__ before__ the commands exit with an error code.
|
||||
|
||||
import subprocess
|
||||
|
||||
output = subprocess.check_output(
|
||||
'echo to stdout; echo to stderr 1>&2; exit 1',
|
||||
**shell=True**,
|
||||
)
|
||||
print 'Have %d bytes in output' % len(output)
|
||||
print output
|
||||
|
||||
|
||||
The message to standard error is printed to the console, but the __message to standard output is hidden__.
|
||||
这是因为如果子进程没有成果执行,被__捕获的标准输出会被丢弃__,而stderr被**输出到终端**。
|
||||
|
||||
$ python subprocess_check_output_error.py
|
||||
|
||||
__to stderr__
|
||||
Traceback (most recent call last):
|
||||
File "subprocess_check_output_error.py", line 14, in <module>
|
||||
shell=True,
|
||||
File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.
|
||||
7/subprocess.py", line 537, in check_output
|
||||
raise CalledProcessError(retcode, cmd, output=output)
|
||||
subprocess.CalledProcessError: Command 'echo to stdout; echo to stderr
|
||||
1>&2; exit 1' returned non-zero exit status 1
|
||||
|
||||
To prevent error messages from commands run through check_output() from being written to the console, set the stderr parameter to the constant __STDOUT__.
|
||||
|
||||
import subprocess
|
||||
|
||||
output = subprocess.check_output(
|
||||
'echo to stdout; echo to stderr 1>&2; exit 1',
|
||||
shell=True,
|
||||
stderr=subprocess.STDOUT, #子进程的标准出错被重定向到**该进程的标准输出流**中,因此子进程的__标准出错流也会被捕获__。
|
||||
)
|
||||
print 'Have %d bytes in output' % len(output)
|
||||
print output
|
||||
|
||||
|
||||
|
||||
Now the error and standard output channels are __merged together__ so if the command prints error messages, __they are captured__ and not sent to the console.
|
||||
|
||||
$ python subprocess_check_output_error_trap_output.py
|
||||
|
||||
Traceback (most recent call last):
|
||||
File "subprocess_check_output_error_trap_output.py", line 15, in <module>
|
||||
stderr=subprocess.STDOUT,
|
||||
File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/subprocess.py", line 537, in check_output
|
||||
raise CalledProcessError(retcode, cmd, output=output)
|
||||
subprocess.CalledProcessError: Command 'echo to stdout; echo to stderr 1>&2; exit 1' returned non-zero exit status 1
|
||||
|
||||
===== Working with Pipes Directly =====
|
||||
|
||||
By passing different arguments for **stdin, stdout, and stderr** it is possible to mimic the variations of os.popen().
|
||||
|
||||
==== popen ====
|
||||
|
||||
To run a process and **read all of its output**, set the stdout value to __PIPE__ and call __communicate()__.
|
||||
PIPE是在subprocess模块中定义的__全局变量,还有STDOUT__。
|
||||
|
||||
import subprocess
|
||||
|
||||
print '\nread:'
|
||||
proc = subprocess.Popen(['echo', '"to stdout"'], #如果使用的是列表,则shell应该设置为False。
|
||||
**stdout**=subprocess.__PIPE__,
|
||||
)
|
||||
#proc为一个**Popen实例**。
|
||||
stdout_value = proc.communicate()__[0] #向子进程发送空内容,然后捕获它的所有标准输出和标准出错,直到子进程退出。使用此方法时,Popen()应该使用PIPE。__
|
||||
print '\tstdout:', repr(stdout_value)
|
||||
|
||||
This is similar to the way popen() works, except that the reading is managed internally by the **Popen instance**.
|
||||
|
||||
$ python subprocess_popen_read.py
|
||||
|
||||
|
||||
read:
|
||||
stdout: '"to stdout"\n'
|
||||
|
||||
To set up a pipe to allow the calling program to **write data to it**, set __stdin to PIPE__.
|
||||
|
||||
import subprocess
|
||||
|
||||
print '\nwrite:'
|
||||
proc = subprocess.Popen(['cat', '-'],
|
||||
__stdin=subprocess.PIPE__,
|
||||
)
|
||||
proc.communicate('\tstdin: to stdin\n')
|
||||
|
||||
To send data to the standard input channel of the process **one time**, pass the data to communicate(). This is similar to using popen() with mode 'w'.
|
||||
|
||||
$ python -u subprocess_popen_write.py
|
||||
|
||||
|
||||
write:
|
||||
stdin: to stdin
|
||||
|
||||
==== popen2 ====
|
||||
|
||||
To set up the Popen instance for__ reading and writing__, use a combination of the previous techniques.
|
||||
|
||||
import subprocess
|
||||
|
||||
print '\npopen2:'
|
||||
|
||||
proc = subprocess.Popen(['cat', '-'],
|
||||
** stdin**=subprocess.PIPE,
|
||||
**stdout**=subprocess.PIPE,
|
||||
)
|
||||
stdout_value = proc.communicate('through stdin to stdout')__[0]__
|
||||
print '\tpass through:', repr(stdout_value)
|
||||
|
||||
This sets up the pipe to mimic popen2().
|
||||
|
||||
$ python -u subprocess_popen2.py
|
||||
|
||||
|
||||
popen2:
|
||||
pass through: 'through stdin to stdout'
|
||||
|
||||
==== popen3 ====
|
||||
|
||||
It is also possible watch both of the streams for **stdin、stdout and stderr**, as with popen3().
|
||||
|
||||
import subprocess
|
||||
|
||||
print '\npopen3:'
|
||||
proc = subprocess.Popen('cat -; echo "to stderr" 1>&2',
|
||||
shell=True,
|
||||
stdin=subprocess.PIPE,
|
||||
stdout=subprocess.PIPE,
|
||||
stderr=subprocess.PIPE,
|
||||
)
|
||||
**stdout_value, stderr_value** = proc.communicate('through stdin to stdout')
|
||||
print '\tpass through:', repr(stdout_value)
|
||||
print '\tstderr :', repr(stderr_value)
|
||||
|
||||
Reading from stderr works the same as with stdout. Passing PIPE tells Popen to attach to the channel, and communicate() reads all of the data from it before returning.
|
||||
|
||||
$ python -u subprocess_popen3.py
|
||||
|
||||
|
||||
popen3:
|
||||
pass through: 'through stdin to stdout'
|
||||
stderr : 'to stderr\n'
|
||||
|
||||
==== popen4 ====
|
||||
|
||||
To** direct the error output from the process to its standard output channel**, use __STDOUT __for stderr instead of PIPE.
|
||||
|
||||
import subprocess
|
||||
|
||||
print '\npopen4:'
|
||||
proc = subprocess.Popen('cat -; echo "to stderr" 1>&2',
|
||||
shell=True,
|
||||
stdin=subprocess.PIPE,
|
||||
stdout=subprocess.PIPE,
|
||||
** stderr=subprocess.STDOUT**,
|
||||
)
|
||||
stdout_value, stderr_value = proc.communicate('through stdin to stdout\n')
|
||||
print '\tcombined output:', repr(stdout_value)
|
||||
print '\tstderr value :', repr(stderr_value)
|
||||
|
||||
Combining the output in this way is similar to how popen4() works.
|
||||
|
||||
$ python -u subprocess_popen4.py
|
||||
|
||||
|
||||
popen4:
|
||||
combined output: 'through stdin to stdout\nto stderr\n'
|
||||
stderr value : None
|
||||
|
||||
===== Connecting Segments of a Pipe =====
|
||||
|
||||
Multiple commands can be connected into a pipeline, similar to the way the Unix shell works, by creating separate Popen instances and__ chaining their inputs and outputs together__. The stdout attribute of one Popen instance is used as the stdin argument for the next in the pipeline, instead of the constant PIPE. The output is read from the stdout handle for the** final** command in the pipeline.
|
||||
|
||||
import subprocess
|
||||
|
||||
cat = subprocess.Popen(['cat', 'index.rst'],
|
||||
stdout=subprocess.PIPE,
|
||||
)
|
||||
|
||||
grep = subprocess.Popen(['grep', '.. include::'],
|
||||
stdin=cat.stdout, #本子进程的标准输入__通过pipe__和上一个进程的标准输出相连。
|
||||
stdout=subprocess.__PIPE__,
|
||||
)
|
||||
|
||||
cut = subprocess.Popen(['cut', '-f', '3', '-d:'],
|
||||
stdin=grep.stdout,
|
||||
stdout=subprocess.PIPE,
|
||||
)
|
||||
|
||||
end_of_pipe = __cut.stdout #返回一个文件对象。__
|
||||
|
||||
print 'Included files:'
|
||||
for line in end_of_pipe: #打印文件中的所有行。
|
||||
print '\t', line.strip()
|
||||
|
||||
This example reproduces the command line cat index.rst | grep ".. include" | cut -f 3 -d:, which reads the reStructuredText source file for this section and finds all of the lines that include other files, then prints only the filenames.
|
||||
|
||||
$ python -u subprocess_pipes.py
|
||||
|
||||
Included files:
|
||||
subprocess_os_system.py
|
||||
subprocess_shell_variables.py
|
||||
subprocess_check_call.py
|
||||
subprocess_check_output.py
|
||||
subprocess_check_output_error.py
|
||||
subprocess_check_output_error_trap_output.py
|
||||
subprocess_popen_read.py
|
||||
subprocess_popen_write.py
|
||||
subprocess_popen2.py
|
||||
subprocess_popen3.py
|
||||
subprocess_popen4.py
|
||||
subprocess_pipes.py
|
||||
repeater.py
|
||||
interaction.py
|
||||
signal_child.py
|
||||
signal_parent.py
|
||||
subprocess_signal_parent_shell.py
|
||||
subprocess_signal_setsid.py
|
||||
|
||||
===== Interacting with Another Command =====
|
||||
|
||||
All of the above examples assume a limited amount of interaction. The **communicate() **method reads __all __of the output and__ waits __for child process to exit before returning. It is also possible to write to and read from the** individual pipe handles** used by the Popen instance. A simple echo program that reads from standard input and writes to standard output illustrates this:
|
||||
|
||||
import **sys**
|
||||
|
||||
__sys.stderr__.write('repeater.py: starting\n')
|
||||
sys.stderr.flush()
|
||||
|
||||
while True:
|
||||
next_line = **sys.stdin.readline()**
|
||||
if not next_line:
|
||||
break
|
||||
sys.stdout.write(next_line)
|
||||
sys.stdout.flush()
|
||||
|
||||
sys.stderr.write('repeater.py: exiting\n')
|
||||
sys.stderr.flush()
|
||||
|
||||
The script, repeater.py, writes to stderr when it starts and stops. That information can be used to show the__ lifetime__ of the child process.
|
||||
|
||||
The next interaction example uses the stdin and stdout file handles __owned by the Popen instance__ in different ways. In the first example, a sequence of 10 numbers are written to stdin of the process, and after each write the next line of output is read back. In the second example, the same 10 numbers are written but the output is __read all at once __using communicate().
|
||||
|
||||
import subprocess
|
||||
|
||||
print 'One line at a time:'
|
||||
proc = subprocess.Popen('python repeater.py',
|
||||
shell=True,
|
||||
** stdin=subprocess.PIPE,**
|
||||
** stdout=subprocess.PIPE,**
|
||||
)
|
||||
for i in range(10):
|
||||
__proc.stdin.write__('%d\n' % i)
|
||||
output = __proc.stdout.readline__()
|
||||
print output.rstrip()
|
||||
remainder = proc.communicate__()__[0] #发送空字符,因此子进程认为是读到文件结束符__因此终止__。
|
||||
print remainder
|
||||
|
||||
print
|
||||
print 'All output at once:'
|
||||
proc = subprocess.Popen('python repeater.py',
|
||||
shell=True,
|
||||
stdin=subprocess.PIPE,
|
||||
stdout=subprocess.PIPE,
|
||||
)
|
||||
for i in range(10):
|
||||
proc.stdin.write('%d\n' % i)
|
||||
|
||||
output = proc.communicate()[0]
|
||||
print output
|
||||
|
||||
The "repeater.py: exiting" lines **come at different points** in the output for each loop style.
|
||||
|
||||
$ python -u interaction.py
|
||||
|
||||
One line at a time:
|
||||
repeater.py: starting
|
||||
0
|
||||
1
|
||||
2
|
||||
3
|
||||
4
|
||||
5
|
||||
6
|
||||
7
|
||||
8
|
||||
9
|
||||
repeater.py: exiting
|
||||
|
||||
|
||||
All output at once:
|
||||
repeater.py: starting
|
||||
repeater.py: exiting
|
||||
0
|
||||
1
|
||||
2
|
||||
3
|
||||
4
|
||||
5
|
||||
6
|
||||
7
|
||||
8
|
||||
9
|
||||
|
||||
===== Signaling Between Processes =====
|
||||
每个Popen实例都有多个属性如:pid, returncode, stdin, stdout, stderr。
|
||||
|
||||
The os examples include a demonstration of __signaling between processes__ using **os.fork() and os.kill()**. Since__ each Popen instance provides a pid attribute__ with the process id of the child process, it is possible to do something similar with subprocess. For example, using this script for the child process to be executed by the parent process
|
||||
|
||||
#子进程源文件(signal_child.py):
|
||||
import **os**
|
||||
import **signal**
|
||||
import **time**
|
||||
import** sys**
|
||||
|
||||
pid = os.getpid()
|
||||
received = False
|
||||
|
||||
def signal_usr1(signum, frame):
|
||||
"Callback invoked when a signal is received"
|
||||
global received
|
||||
received = True
|
||||
print 'CHILD %6s: Received USR1' % pid
|
||||
__ sys.stdout.flush()__
|
||||
|
||||
print 'CHILD %6s: Setting up signal handler' % pid
|
||||
sys.stdout.flush()
|
||||
signal.signal(__signal.SIGUSR1__, signal_usr1)
|
||||
print 'CHILD %6s: Pausing to wait for signal' % pid
|
||||
sys.stdout.flush()
|
||||
time.sleep(3)
|
||||
|
||||
if not received:
|
||||
print 'CHILD %6s: Never received signal' % pid
|
||||
|
||||
combined with this parent process
|
||||
|
||||
import os
|
||||
import signal
|
||||
import subprocess
|
||||
import time
|
||||
import sys
|
||||
|
||||
proc = subprocess.Popen(['python', 'signal_child.py']) #子进程在后台执行。
|
||||
print 'PARENT : Pausing before sending signal...'
|
||||
sys.stdout.flush()
|
||||
time.sleep(1) #这个sleep是为了与子进程同步。
|
||||
print 'PARENT : Signaling child'
|
||||
sys.stdout.flush()
|
||||
__os.kill(proc.pid, signal.SIGUSR1)__
|
||||
|
||||
the output is:
|
||||
|
||||
$ python signal_parent.py
|
||||
|
||||
PARENT : Pausing before sending signal...
|
||||
CHILD 11668: Setting up signal handler
|
||||
CHILD 11668: Pausing to wait for signal
|
||||
PARENT : Signaling child
|
||||
CHILD 11668: Received USR1
|
||||
|
||||
===== Process Groups / Sessions =====
|
||||
|
||||
Because of the way the__ process tree__ works under Unix, if the process created by **Popen spawns sub-processes**, those children will not receive any signals sent to the parent. That means, for example, it will be difficult to cause them to terminate by sending SIGINT or SIGTERM.
|
||||
|
||||
import os
|
||||
import signal
|
||||
import subprocess
|
||||
import **tempfile**
|
||||
import time
|
||||
import sys
|
||||
|
||||
__script__ = '''#!/bin/sh
|
||||
echo "Shell script in process $$"
|
||||
set -x
|
||||
python signal_child.py
|
||||
'''
|
||||
**script_file** = tempfile.__NamedTemporaryFile__('wt')
|
||||
script_file.write(script)
|
||||
script_file.flush()
|
||||
|
||||
proc = subprocess.Popen(['sh', script_file.__name__], close_fds=True)
|
||||
print 'PARENT : Pausing before sending signal to child %s...' % proc.pid
|
||||
sys.stdout.flush()
|
||||
time.sleep(1)
|
||||
print 'PARENT : Signaling child %s' % proc.pid
|
||||
sys.stdout.flush()
|
||||
os.kill(proc.__pid__, signal.SIGUSR1)
|
||||
time.sleep(3)
|
||||
|
||||
The pid used to send the signal does not match the pid of the child of the shell script waiting for the signal because in this example, there are __three separate__ processes interacting:
|
||||
|
||||
* subprocess_signal_parent_shell.py
|
||||
* __The Unix shell__ process **running the script** created by the main python program.
|
||||
* signal_child.py
|
||||
|
||||
$ python subprocess_signal_parent_shell.py
|
||||
|
||||
PARENT : Pausing before sending signal to child 11671...
|
||||
Shell script in process 11671
|
||||
+ python signal_child.py
|
||||
CHILD 11672: Setting up signal handler
|
||||
CHILD 11672: Pausing to wait for signal
|
||||
PARENT : Signaling child 11671
|
||||
CHILD 11672: Never received signal
|
||||
|
||||
The solution to this problem is to__ use a process group__ to associate the children so they can **be signaled together**. The process group is created with __os.setsid()__, setting the “session id” to the process id of the current process. All child processes** inherit the session id**, and since it should **only be set set in the shell created by Popen and its descendants,** os.setsid() __should not be called in the parent process__. Instead, the function is passed to Popen as the __preexec_fn__ argument so it is run **after the fork() inside the new process, before it uses exec() to run the shell**.
|
||||
|
||||
import os
|
||||
import signal
|
||||
import subprocess
|
||||
import tempfile
|
||||
import time
|
||||
import sys
|
||||
|
||||
script = '''#!/bin/sh
|
||||
echo "Shell script in process $$"
|
||||
set -x
|
||||
python signal_child.py
|
||||
'''
|
||||
script_file = tempfile.NamedTemporaryFile('wt')
|
||||
script_file.write(script)
|
||||
script_file.flush()
|
||||
|
||||
proc = subprocess.Popen(['sh', script_file.name],
|
||||
close_fds=True,
|
||||
__preexec_fn=os.setsid__,
|
||||
) #在fork后执行(exec)sh前执行os.setsid,这样__shell和ignal_child.py进程都在一个进程组中__。注意,这里的shell为__非交互式shell__,所以它在执行脚本时不会将脚本放在另一个进程组中以实现交互式shell的前后台命令的功能。
|
||||
|
||||
print 'PARENT : Pausing before sending signal to child %s...' % proc.pid
|
||||
sys.stdout.flush()
|
||||
time.sleep(1)
|
||||
print 'PARENT : Signaling process group %s' % proc.pid
|
||||
sys.stdout.flush()
|
||||
__os.killpg__(__proc.pid__, signal.SIGUSR1)
|
||||
time.sleep(3)
|
||||
|
||||
The sequence of events is:
|
||||
|
||||
The parent program instantiates Popen.
|
||||
The Popen instance forks a new process.
|
||||
The new process runs os.setsid().
|
||||
The new process runs exec() to start the shell.
|
||||
The shell runs the shell script.
|
||||
The shell script forks again and that process execs Python.
|
||||
Python runs signal_child.py.
|
||||
The parent program signals the process group using the pid of the shell.
|
||||
The shell and Python processes receive the signal. The shell ignores it. Python invokes the signal handler.
|
||||
|
||||
To signal the **entire process group**, use __os.killpg()__ with the pid value from the Popen instance.
|
||||
|
||||
$ python subprocess_signal_setsid.py
|
||||
|
||||
PARENT : Pausing before sending signal to child 11676...
|
||||
Shell script in process 11676
|
||||
+ python signal_child.py
|
||||
CHILD 11677: Setting up signal handler
|
||||
CHILD 11677: Pausing to wait for signal
|
||||
PARENT : Signaling process group 11676
|
||||
CHILD 11677: Received USR1
|
||||
|
||||
===== See also =====
|
||||
|
||||
* **subprocess**
|
||||
Standard library documentation for this module.
|
||||
* os
|
||||
Although many are deprecated, the functions for working with processes found in the os module are still widely used in existing code.
|
||||
* UNIX SIgnals and Process Groups
|
||||
A good description of UNIX signaling and how process groups work.
|
||||
* Advanced Programming in the UNIX(R) Environment
|
||||
Covers working with multiple processes, such as handling signals, closing duplicated file descriptors, etc.
|
||||
* pipes
|
||||
Unix shell command pipeline templates in the standard library.
|
||||
|
||||
|
||||
|
||||
=================================================================
|
||||
|
||||
|
||||
Doug Hellmann
|
||||
It isn't clear if you're working exactly with the example program or if you have modified it.** When stdin is set to PIPE the new process will block trying to read input.** __The parent has to write something or close the stdin handle to send an end-of-file to the new process so it will have data to read so it does not block.__
|
||||
Like
|
||||
Reply
|
||||
3 months ago
|
||||
in reply to cheenu
|
||||
Vincent
|
||||
Note that by default the value for the __"bufsize" parameter of Popen is 0__, which means that stream communications are** not buffered**, resulting in a drop of performance if your process yields a lot of information on stdout/stderr.
|
||||
Setting bufsize to__ -1 __improves the situation a lot !
|
||||
|
||||
|
||||
I'm trying to make a python script that will log me onto a ssh server and then pass over the controls to me in the terminal.
|
||||
So far I have:
|
||||
import subprocess
|
||||
proc = subprocess.call('ssh -t -t USERserver ',shell=True,)
|
||||
|
||||
But I cannot get it so that the python script can interact with ssh session and enter password and then pass over control to terminal user.
|
||||
|
||||
Like
|
||||
Reply
|
||||
6 months ago
|
||||
Doug Hellmann
|
||||
You probably need to set stdin and stdout for the process. You should be able to get more help on comp.lang.python.
|
||||
Like
|
||||
Reply
|
||||
6 months ago
|
||||
in reply to Scott S
|
||||
nerd
|
||||
The "Python Version: 2.4 and later" indicator at the top of this article is incorrect as "check_output" was not released until python 2.7
|
||||
|
||||
|
||||
Doug
|
||||
Wow. helpful in so many ways, especially that last bit about__ setting a process group and using os.killpg()__. I'm not sure I would have ever gotten that right just reading from the docs. I ran into the same issue...trying to end the child process, which was the shell, not realizing that the script the shell was executing was a __third process__, so it would always hang. I got around it by using "sh exec mycommand" but that might not work in every case, and I'm not sure what other side effects may be lurking because of it. Thanks again.
|
||||
Like
|
||||
|
||||
barbara
|
||||
Ha, thank you for this - I was poking around online last night looking for some help when I came across this post and had a lightbulb moment. :)
|
||||
Like
|
||||
Reply
|
||||
2 years ago
|
||||
Doug Hellmann
|
||||
What platform are you on @pythonnewb? It sounds like the repeater.py file needs to have its permissions changed from the way they are packaged by default.
|
||||
Like
|
||||
Reply
|
||||
2 years ago
|
||||
pythonnewb
|
||||
Ok, i get it..
|
||||
|
||||
here is an example
|
||||
|
||||
import __urllib2__
|
||||
import subprocess
|
||||
|
||||
|
||||
openurl = urllib2.urlopen(''http........')
|
||||
grep = subprocess.Popen('grep HEAD',
|
||||
shell=True,
|
||||
stdin=subprocess.PIPE,
|
||||
stdout=subprocess.PIPE,
|
||||
stderr=subprocess.STDOUT
|
||||
)
|
||||
grep_stdout=grep.communicate(openurl.read(3000))[0]
|
||||
|
||||
print(grep_stdout)
|
||||
@@ -0,0 +1,148 @@
|
||||
Content-Type: text/x-zim-wiki
|
||||
Wiki-Format: zim 0.4
|
||||
Creation-Date: 2012-01-06T13:47:03+08:00
|
||||
|
||||
====== virtualenvwrapper ======
|
||||
Created Friday 06 January 2012
|
||||
http://mathematism.com/2009/07/30/presentation-pip-and-virtualenv/
|
||||
|
||||
Jul 30
|
||||
Presentation: pip and virtualenv
|
||||
|
||||
I put together a walkthrough of __pip__ and __virtualenv __for the django-district July meeting. It was a slide-less presentation, focusing mostly on talking points and command-line walkthroughs. This post provides a recap of what I covered.
|
||||
|
||||
===== virtualenv =====
|
||||
virtualenv is a tool to create** isolated Python environments**. It was created by Ian Bicking to provide a solution to a consistent problem.
|
||||
|
||||
===== The Problem =====
|
||||
To illustrate the problem let’s pretend you have a Web server with two Web sites on it: mysite.com and anothersite.com. Each of your Web sites are sharing the **global site-packages** directory in /usr/lib/python2.x/site-packages.
|
||||
{{./1.jpg}}
|
||||
The global site-packages directory has Django 1.0.2, Pinax 0.5 and PIL 1.1.6 among other things. The sites are purring along, living in complete harmony.
|
||||
|
||||
One day, the client for anothersite.com decides they’d like to take advantage of some of the new features in Django 1.1. Now we have a problem. How do we upgrade anothersite.com’s dependencies without affecting mysite.com?
|
||||
|
||||
===== The Solution =====
|
||||
anothersite.com and mysite.com need the ability to have __their own set of dependencies__. The way to achieve this is to create isolated Python environments using __virtualenv__.
|
||||
{{./2.jpg}}
|
||||
virtualenv creates an environment that has__ its own installation directories__ and isolates itself from other virtual environments. The environment contains** a site-packages directory**, installs__ setuptools__ and a Python interpreter that is **aware of its environment**.
|
||||
|
||||
This allows us to install a different set of dependencies for each of our sites. Now anothersite.com can upgrade to Django 1.1 and Pinax trunk without affecting mysite.com at all.
|
||||
|
||||
===== Installation =====
|
||||
virtualenv is available on **PyPI**. Run the following command to install:
|
||||
|
||||
//easy_install virtualenv//
|
||||
|
||||
===== Working with virtualenv =====
|
||||
While I could go into detail about the commands available with virtualenv, I honestly never use the virtualenv commands directly. I use suite of conveniences for virtualenv called __virtualenvwrapper__.
|
||||
|
||||
===== virtualenvwrapper =====
|
||||
Doug Hellmann was kind enough to create virtualenvwrapper, which is best described on PyPI:
|
||||
|
||||
virtualenvwrapper is **a set of extensions** to Ian Bicking’s virtualenv tool. The extensions include wrappers for creating and deleting virtual environments and otherwise managing your development workflow, making it easier to work on more than one project at a time without introducing conflicts in their dependencies.
|
||||
|
||||
===== Screencast =====
|
||||
I put together a quick screencast to go over the wrappers and hooks that virtualenvwrapper provides as stated below. You can also view the source code on Bitbucket. Doug’s code is well commented and I found out about several of these wrappers only after taking a look at the source.
|
||||
|
||||
===== Wrappers =====
|
||||
The wrappers provided by **virtualenvwrapper** (that I know of) are:
|
||||
下面的封装函数只有当用source /path/to/virtualenvwrapper.sh后才有效。
|
||||
* mkvirtualenv (create a new virtualenv)
|
||||
* rmvirtualenv (remove an existing virtualenv)
|
||||
* workon (change the current virtualenv)
|
||||
* add2virtualenv (add __external packages__ in a .pth file to current virtualenv)
|
||||
* cdsitepackages (cd into the site-packages directory of **current** virtualenv)
|
||||
* cdvirtualenv (cd into the__ root__ of the current virtualenv)
|
||||
* deactivate (deactivate virtualenv, which calls several hooks)
|
||||
|
||||
===== Hooks =====
|
||||
One of the coolest things about virtualenvwrapper is the ability to provide hooks __when an event occurs__. Hook files can be placed in ENV/bin/ and are simply plain-text files with __shell commands__. virtualenvwrapper provides the following hooks:
|
||||
|
||||
* postmkvirtualenv
|
||||
* prermvirtualenv
|
||||
* postrmvirtualenv
|
||||
* postactivate
|
||||
* predeactivate
|
||||
* postdeactivate
|
||||
|
||||
===== Installation =====
|
||||
virtualenvwrapper is available on __PyPI__. Run the following command to install:
|
||||
|
||||
//easy_install virtualenvwrapper//
|
||||
|
||||
Add two lines to your__ .bashrc__ to set the location where the virtual environments should live and the location of the script installed with this package:
|
||||
|
||||
//export WORKON_HOME=$HOME/.virtualenvs//
|
||||
//source /usr/local/bin/virtualenvwrapper_bashrc//
|
||||
|
||||
You should also take a look at Doug’s blog post on virtualenvwrapper, which provides a great overview of why he created virtualenvwrapper and provides detailed setup instructions.
|
||||
|
||||
===== pip(easy_install的替代者,提供自动搜索、安装、移除,以及依赖文件) =====
|
||||
Another tool created by Ian Bicking, __pip stands for pip installs Python packages.__ It is a replacement for easy_install that provides some great improvements including requirements files and support for version control systems.
|
||||
|
||||
==== Requirements files ====
|
||||
Requirements files are plain text files that contain **a list of packages to be installed**. These text files allow you to create __repeatable installations__. As illustrated in this example file, there are several ways to specify a required package.
|
||||
|
||||
Package name with version requirements:
|
||||
|
||||
Django>=1.1
|
||||
Pinax==0.5
|
||||
|
||||
Direct URL to a tarball containing a setup.py script:
|
||||
|
||||
http://effbot.org/downloads/Imaging-1.1.6.tar.gz
|
||||
|
||||
Editable checkouts from VCS repositories:
|
||||
|
||||
-e svn+http://svn.myproject.org/svn/MyProject/trunk#egg=MyProject
|
||||
-e git+http://git.myproject.org/MyProject/#egg=MyProject
|
||||
-e hg+ssh://hg@myproject.org/MyProject/#egg=MyProject
|
||||
-e bzr+https://bzr.myproject.org/MyProject/trunk#egg=MyProject
|
||||
|
||||
Editable checkouts from VCS repositories with revision information:
|
||||
|
||||
-e svn+http://svn.myproject.org/svn/MyProject/trunk@2019#egg=MyProject
|
||||
-e git://git.myproject.org/MyProject.git@da39a3ee5e6b4b0d3255bfef95601890afd80709#egg=MyProject
|
||||
-e hg+http://hg.myproject.org/MyProject/@2019#egg=MyProject
|
||||
-e bzr+https://bzr.myproject.org/MyProject/trunk/@2019#egg=MyProject
|
||||
|
||||
View my sample requirements file for more examples of checking out with revision information including branches, tags and dates.
|
||||
|
||||
===== Usage =====
|
||||
Once you have a requirements file, Installing a package using **pip** is as simple as the following command:
|
||||
|
||||
__pip install -r /path/to/requirements.txt__
|
||||
|
||||
I should note that you don’t have to create a requirements file. You can simply issue any of the commands listed in the requirements file directly from the command line like so:
|
||||
|
||||
__pip install Django>=1.1__
|
||||
pip install http://effbot.org/downloads/Imaging-1.1.6.tar.gz
|
||||
pip install -e svn+http://myrepo/svn/MyApp#egg=MyApp
|
||||
|
||||
===== pip freeze =====
|
||||
打印出**当前环境中所有非标准package名称及其版本号**,非常方便与复制当前环境。
|
||||
|
||||
pip doesn’t just install packages. It also provides a few other commands, including freeze:
|
||||
|
||||
pip freeze > /path/to/requirements.txt
|
||||
|
||||
This will __inspect the current environment and generate a requirements files that contains explicit version number__ for each of the installed packages. I generally use this as a starting point for creating a stable requirements file.
|
||||
|
||||
There are other commands as well. I’d encourage you to take a look at the documentation for pip to learn more about the various options.
|
||||
|
||||
===== Installation =====
|
||||
|
||||
pip is available on PyPI. Run the following command to install:
|
||||
|
||||
**easy_install pip**
|
||||
|
||||
You can also check out a copy from bitbucket. Run one of the following commands:
|
||||
wget http://bitbucket.org/ianb/pip/raw/0.4/pip.py
|
||||
|
||||
OR
|
||||
|
||||
hg clone http://bitbucket.org/ianb/pip/
|
||||
|
||||
===== Conclusion =====
|
||||
|
||||
Using __virtualenv, virtualenvwrapper and pip__ together can help you create__ isolated, repeatable environments __with ease. We use these tools on a daily basis at Discovery Creative and it has saved us countless hours in addition to providing documentation for requirements for our applications and sites.
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 17 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 22 KiB |
Reference in New Issue
Block a user