In short, execution context is just a collection of data private to a request, a bunch of items that invisibly accompanies the request in the course of its execution. At any point your application modules could read the context values or modify them. Execution context thus belongs to the logical thread of execution which processes the request, even though this logical thread engages multiple physical threads or even crosses the machine boundaries.

As the modules pass control from one to another by either a local call or some form of a cage-to-cage call

result = pmnc.target_module.target_method(...)
result = pmnc.execute.on("target_cage").target_module.target_method(...)
...

each method's knowledge about the request being processed is limited to its arguments. While this is a correct approach from modularization point of view, in practice there appear situations where a method needs to know something else, totally beyond its signature.

The typical questions of that kind are - what was the IP address of the original web service client (or, in case you've done it properly - which role does current caller belong ?). Or, if you implement a continuous self-testing of a running service - is the request being processed real ? Because if it is not real but rather a test invoked every 5 minutes, there is no need to send mail to the administrator when it completes.

Given the above questions, what choice do you have ? You either append these pieces of information as an explicit arguments to each method on the trail

pmnc.module.method(..., client_role = "user", test_run = True)

or even declare that all methods take some special parameter in which such "extra" information is hidden:

pmnc.pmnc.module.method(..., context = { "client_role": "user", "test_run": True })

and this is exactly what the request context is, except for it is provided by Pythomnic and you don't need to bother maintaining it or passing from one call to another.