http://code.activestate.com/recipes/tags/global/popular/2017-06-22T10:24:05-07:00ActiveState Code Recipes2017-06-22T10:24:05-07:00Alfehttp://code.activestate.com/recipes/users/4182236/http://code.activestate.com/recipes/578147-stack-environment/

<p style="color: grey"> Python recipe 578147 by <a href="/recipes/users/4182236/">Alfe</a> (<a href="/recipes/tags/environment/">environment</a>, <a href="/recipes/tags/global/">global</a>, <a href="/recipes/tags/stack/">stack</a>, <a href="/recipes/tags/stackenv/">stackenv</a>, <a href="/recipes/tags/variable/">variable</a>). Revision 3. </p> <p>The environment variables of processes get inherited by their children who can modify them and pass them on to their children. The tree of processes is similar to the call tree of a running Python process, but a similar mechanism like the environment variables is missing. I'm offering a solution for this; each stack frame takes the place of a process, hence I call it StackEnv. It comes in handy if you want to pass information from one frame to a frame far below without patching all the calls in between to pass the data (which might belong to a framework you don't want to change).</p> <p>Usecases:</p> <ol> <li><p>You call a framework which calls back your code before returning (e. g. in passed objects you provide). You want to pass some information to your code without relying on global variables or similar constructs which weren't thread-safe nor re-entrant.</p></li> <li><p>You want to pass pseudo-global but in fact situation-related information (e. g. the verbosity based on the situation the call comes from) without handing the information down in each and every call which can happen below yours.</p></li> <li><p>You want to give called methods the option to override the decision of the caller method regarding this information. (E. g. the caller decides that verbosity should be True, but the called method then calls another method and decides that the verbosity in this case should be False.)</p></li> </ol> <p>Alike processes, called frames cannot influence the values for calling frames (but of course mutable values <em>can</em> be used to pass information upwards; this normal kind of "abuse" isn't prevented).</p> <p>Importing:</p> <pre class="prettyprint"><code>from stackEnv import stackEnv </code></pre> <p>Setting a stackEnv variable:</p> <pre class="prettyprint"><code>stackEnv.verbose = True </code></pre> <p>Using the value of a stackEnv variable:</p> <pre class="prettyprint"><code>if stackEnv.verbose: print "being verbose now" </code></pre> <p>Testing a stackEnv variable:</p> <pre class="prettyprint"><code>if 'verbose' in stackEnv: print "having information on verbosity" </code></pre> <p>Overriding a stackEnv variable's value for the rest of this frame and its calls:</p> <pre class="prettyprint"><code>stackEnv.verbose = False </code></pre> <p>Removing a stackEnv variable for the rest of this frame and its calls:</p> <pre class="prettyprint"><code>del stackEnv.verbose </code></pre> <p>Some more useful API of this class can be found in the unit test included.</p>