正如书中所说，我只把它用作临时占位符，也就是说，

# code that does something to to a variable, var
if var == 2000:
    pass
else:
    var += 1

然后填充var == 2000的场景。

pass语句什么也不做。当语法上需要语句，但程序不需要操作时，可以使用它。

首先，如果你想写一个block，像这样:

if statement:
    pass
for i in range(abc):
    pass
def func():
    pass

pass can是一个占位符。

其次，它可以让你与IDE“交流”: 当你想让你的IDE像这样递减缩进: 如果你的程序写在这里:

class abc(parent):
    def __init__(self, params):
        self.params=params
        if d:
            return
        else:
            return
        # cursor in there

现在你的缩进计数是2，但你希望它在下一行是1。 你可以输入一个pass，你的程序是这样的:

class abc(parent):
    def __init__(self, params):
        self.params=params
        if d:
            return
        else:
            return
        pass# cursor in there

并返回。它会让你快乐:

class abc(parent):
    def __init__(self, params):
        self.params=params
        if d:
            return
        else:
            return
        pass
    # cursor in there

现在缩进计数是1。

Pass只是空的表示代码。

例如，pass用于创建一个空类或函数，如下所示:

class Test:
    pass

def test():
    pass

但是，如果一个类或函数真的没有任何东西，甚至通过如下所示:

class Test:
    # pass

def test():
    # psss

出现如下错误:

SyntaxError:解析时意外的EOF

正如我之前所说，pass只是空的指示代码，所以如果在pass之后有一些代码，代码的工作方式如下所示:

class Test:
    pass
    x = "Hello World"

def test():
    pass
    return "Hello World"

print(Test.x) # Hello World
print(test()) # Hello World

如果你想导入一个模块，如果它存在，并且忽略导入它，如果该模块不存在，你可以使用下面的代码:

try:
    import a_module
except ImportError:
    pass
# The rest of your code

如果您避免编写pass语句并继续编写其余代码，则会引发IndentationError，因为打开except块后的行没有缩进。

Python在语法上要求代码块(在if, except, def, class等之后)不能为空。然而，空代码块在各种不同的上下文中都很有用，比如下面的例子，这是我见过的最常见的用例。

因此，如果在代码块中不希望发生任何事情，则需要一个传递以使该代码块不产生IndentationError。或者，任何语句(包括一个要求值的项，如Ellipsis字面量…)可以使用字符串(通常是docstring)，但该传递清楚地表明，实际上不应该发生任何事情，也不需要实际计算并(至少暂时)存储在内存中。

Ignoring (all or) a certain type of Exception (example from xml): try: self.version = "Expat %d.%d.%d" % expat.version_info except AttributeError: pass # unknown Note: Ignoring all types of raises, as in the following example from pandas, is generally considered bad practice, because it also catches exceptions that should probably be passed on to the caller, e.g. KeyboardInterrupt or SystemExit (or even HardwareIsOnFireError – How do you know you aren't running on a custom box with specific errors defined, which some calling application would want to know about?). try: os.unlink(filename_larry) except: pass Instead using at least except Error: or in this case preferably except OSError: is considered much better practice. A quick analysis of all Python modules I have installed gave me that more than 10% of all except ...: pass statements catch all exceptions, so it's still a frequent pattern in Python programming. Deriving an exception class that does not add new behaviour (e.g., in SciPy): class CompileError(Exception): pass Similarly, classes intended as abstract base class often have an explicit empty __init__ or other methods that subclasses are supposed to derive (e.g., pebl): class _BaseSubmittingController(_BaseController): def submit(self, tasks): pass def retrieve(self, deferred_results): pass Testing that code runs properly for a few test values, without caring about the results (from mpmath): for x, error in MDNewton(mp, f, (1,-2), verbose=0, norm=lambda x: norm(x, inf)): pass In class or function definitions, often a docstring is already in place as the obligatory statement to be executed as the only thing in the block. In such cases, the block may contain pass in addition to the docstring in order to say “This is indeed intended to do nothing.”, for example in pebl: class ParsingError(Exception): """Error encountered while parsing an ill-formed datafile.""" pass In some cases, pass is used as a placeholder to say “This method/class/if-block/... has not been implemented yet, but this will be the place to do it”, although I personally prefer the Ellipsis literal ... in order to strictly differentiate between this and the intentional “no-op” in the previous example. (Note that the Ellipsis literal is a valid expression only in Python 3) For example, if I write a model in broad strokes, I might write def update_agent(agent): ... where others might have def update_agent(agent): pass before def time_step(agents): for agent in agents: update_agent(agent) as a reminder to fill in the update_agent function at a later point, but run some tests already to see if the rest of the code behaves as intended. (A third option for this case is raise NotImplementedError. This is useful in particular for two cases: Either “This abstract method should be implemented by every subclass, and there isn't a generic way to define it in this base class”, or “This function, with this name, is not yet implemented in this release, but this is what its signature will look like”)