How to play the Python (5) generator

The invocation of a function satisfies the principle of "last in first out", that is, the function that is called should be the first to return, and the recursive invocation of the function is a classic example. Obviously, in memory in the "last in first out" process of data processing of the stack is the most suitable for the implementation of function call vector, in the compiled programming language, function is called, function parameters, return address, register value and other data will be pressed into the stack, after the completion of the function, the above data pop-up stack. This also means that once a called function is executed, its life cycle is over.

In an interpreted language like Python, the invocation of a function is also dependent on the stack. As I said before, the standard interpreter for Python is written in C. The interpreter executes a Python program with a C function called Pyeval_evalframeex. For a function in Python, the interpreter takes a Python stack frame object and executes the Python bytecode in the context of the stack frame.

Let's take a look at this example:

import disdef foo():    bar()def bar():    pass    print(dis.dis(foo))

We can use the DIS module to view the Python program's bytecode, the following is the byte code of Function foo ():

0 LOAD_GLOBAL              0 (bar)2 CALL_FUNCTION            04 POP_TOP6 LOAD_CONST               0 (None)8 RETURN_VALUE

The Foo function loads the bar into the stack and invokes it, pops the return value from the stack, loads and returns none, and when Pyeval_evalframeex encounters the Call_function bytecode, it creates a new Python stack frame, The new frame is then used recursively to invoke the Pyeval_evalframeex as a parameter to execute bar. One thing to note, though, is that the Python interpreter is a normal C program, so its stack frame is a normal stack. But the python stack frame it operates on is allocated on the heap, so Python's stack frame can survive its invocation. And can be explicitly saved.

This is the technical basis of the Python generator, and here is a generator:

def gen():    yield 1    yield 2g = gen()next(g)print(type(g))

The results returned are:

<class ‘generator‘>

All generators generated by calling Gen () point to the same Code object, but each has its own stack frame. This stack frame does not exist on the actual stack, it waits to be used on the heap memory.

The stack frame has a "last instruction" pointer pointing to the most recently executed instruction. At first, the last instruction pointer is-1 means that the generator has not yet started, which is why the above example has the next (g) line of code. The generator can be executed at any time by any function, because its stack frame is not actually on the stack but on the heap. The location of the generator in the call hierarchy is not fixed, and it does not need to follow the advanced post-out order followed by regular function execution. Because of these features, the generator can be used not only to build an iterative object, but also to implement multi-task collaboration. In the next blog post, I will introduce a very important concept in Python: the Association Process.

How to play the Python (5) generator