Creating Bindings - Page 7

Now, if we continue by creating a variable and importing from modules, we will see a number of bindings created:

>>> z = 2
>>> import math
>>> from cmath import cos
>>> globals()
{'math': <module 'math'>, '__ doc__ ': None, 'z': 2, 'cos':
<built-in function cos
>, '__ name__ ': '__ main__ ', '__ builtins__ ':
  <module '__ builtin__ '>}
>>> locals()
{'math': <module 'math'>, '__ doc__ ': None, 'z': 2, 'cos':
<built-in function cos>, '__ name__ ': '__ main__ ',
  '__ builtins__ ':
<module '__ builtin__ '>}
>>> math. ceil( 3.4)
4.0

[Lines 7 and 8 above are one line as are lines 11 and 12. They have been split for formatting purposes.]

As expected, the local and global namespaces continue to be equivalent. Entries have been added for z as a number, math as a module, and cos from the cmath module as a function.

We can use the del statement to remove these new bindings from the namespace (including the module bindings created with the import statements).

>>> del z, math, cos
>>> locals()
{'__ doc__ ': None, '__ name__ ': '__ main__ ',
  '__ builtins__ ':
<module '__ builtin__ '>}
>>> math. ceil( 3.4)
Traceback (innermost last):
  File "< stdin>", line 1, in ?
NameError: math
>>> import math
>>> math. ceil( 3.4)
4

[Lines 3 and 4 above are one line. They have been split for formatting purposes.]

The result was not drastic, as we were able to import the math module and use it again. Using del in this manner can be handy when in the interactive mode.

For the trigger happy, yes it is also possible to use del to remove the __ doc__, __ main__, and __ builtins__ entries. But resist doing this, as it would not be good for the health of your session!

Now let's take a look at a function created in an interactive session:

>>> def f( x):
… print "global: ", globals()
… print "Entry local: ", locals()
… y = x
… print "Exit local: ", locals()
…
>>> z = 2
>>> globals()
{'f': <function f at 793d0>, '__ doc__ ': None, 'z': 2, '
__ name__ ': '__ main__ ', '__ builtins__ ': <module
  '__ builtin__ '>}
>>> f( z)
global: {'f': <function f at 793cd0>, '__ doc__ ': None, '
z': 2, '__ name__ ': '__ main__ ', '__ builtins__ ': <module
'__ builtin__ '>}
Entry local: {'x': 2}
Exit local: {'x': 2, 'y': 2}
>>>

[Lines 10 and 11 above are one line. They have been split for formatting purposes.]

If we dissect this apparent mess, we see that, as expected, upon entry the parameter x is the original entry in f's local namespace but y is added later. The global namespace is the same as that of our interactive session, as this is where f was defined. Note that it contains z, which was defined after f.

In a production environment we will normally be calling functions that are defined in modules. Their global namespace will be that of the module they are defined in. Assume we've created the following file:

""" scopetest: our scope test module"""
v = 6

def f( x):
  """ f: scope test function"""
  print "global: ", globals(). keys()
  print "entry local:", locals()
  y = x
  w = v
  print "exit local:", locals()

Note that we will be only printing the keys (identifiers) of the dictionary returned by globals. This will reduce the clutter in the results. It was very necessary in this case due to the fact that in modules as an optimization, the whole __ builtin__ dictionary is stored in the value field for the __ builtins__ key.

Library and Third-Party Modules - Page 6
The Quick Python Book
The Built-In Namespace - Page 8