I presume we are discussing Chapter 4. Execution model. I do not see any mention there of the difference between function definition and body execution time. The section of def statements (7.6) has this: "The function definition does not execute the function body; this gets executed only when the function is called. [3]". This is true for lambda expressions also, but nothing is said there. This may contribute to people expecting name resolution of non-parameters in lambda bodies to happen at lambda expression == function definition time rather than later at function call time (what Nick called function execution time).

I think 4.1. Naming and binding should be slightly expanded and renamed 4.1. Name binding and resolution. People need to understand both how and when associations are made and when they are used (as well as what scopes are used). Not understanding this results in the perennial confusion about params with defaults and free names in lambda expressions.

In function headers, param = expr creates a binding when the header is executed, which is when the function object is created. It is stored in the function object. It may optionally be used when the function is called.

In lambda bodies such as in lambda x: x + i, there is no binding of i so i must be bound in a surrounding context either before the function is defined or before the function is called, depending on the surrounding contex, and used when the function is called.

These two facts are somehow not clear enough at present. In any case, my point is the the 'when' part of name binding and use is related to the when of execution.

The relevance of compilation time is more subtle. It is when module, statement, and function code objects are created, including by compile(). If code objects (and compile) are part of the language, then so is compile time. The existence of both interactive statement execution and delayed module execution also has implications for how Python works and how it can and cannot be modified. I am not sure how much to say, though.

Part of the execution model of Python is that, leaving aside i/o, the effect of executing statements is to change user visible name and slot bindings. There are essentially no declarations for changing invisible compiler/interpreter settings.