sam-t2/devtools/amd64/html/python/lib/node774.html

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html>
<head>
<link rel="STYLESHEET" href="lib.css" type='text/css' />
<link rel="SHORTCUT ICON" href="../icons/pyfav.png" type="image/png" />
<link rel='start' href='../index.html' title='Python Documentation Index' />
<link rel="first" href="lib.html" title='Python Library Reference' />
<link rel='contents' href='contents.html' title="Contents" />
<link rel='index' href='genindex.html' title='Index' />
<link rel='last' href='about.html' title='About this document...' />
<link rel='help' href='about.html' title='About this document...' />
<link rel="prev" href="node773.html" />
<link rel="parent" href="node772.html" />
<link rel="next" href="module-symbol.html" />
<meta name='aesop' content='information' />
<title>18.1.6.2 Information Discovery</title>
</head>
<body>
<DIV CLASS="navigation">
<div id='top-navigation-panel' xml:id='top-navigation-panel'>
<table align="center" width="100%" cellpadding="0" cellspacing="2">
<tr>
<td class='online-navigation'><a rel="prev" title="18.1.6.1 Emulation of compile()"
  href="node773.html"><img src='../icons/previous.png'
  border='0' height='32'  alt='Previous Page' width='32' /></A></td>
<td class='online-navigation'><a rel="parent" title="18.1.6 Examples"
  href="node772.html"><img src='../icons/up.png'
  border='0' height='32'  alt='Up One Level' width='32' /></A></td>
<td class='online-navigation'><a rel="next" title="18.2 symbol  "
  href="module-symbol.html"><img src='../icons/next.png'
  border='0' height='32'  alt='Next Page' width='32' /></A></td>
<td align="center" width="100%">Python Library Reference</td>
<td class='online-navigation'><a rel="contents" title="Table of Contents"
  href="contents.html"><img src='../icons/contents.png'
  border='0' height='32'  alt='Contents' width='32' /></A></td>
<td class='online-navigation'><a href="modindex.html" title="Module Index"><img src='../icons/modules.png'
  border='0' height='32'  alt='Module Index' width='32' /></a></td>
<td class='online-navigation'><a rel="index" title="Index"
  href="genindex.html"><img src='../icons/index.png'
  border='0' height='32'  alt='Index' width='32' /></A></td>
</tr></table>
<div class='online-navigation'>
<b class="navlabel">Previous:</b>
<a class="sectref" rel="prev" href="node773.html">18.1.6.1 Emulation of compile()</A>
<b class="navlabel">Up:</b>
<a class="sectref" rel="parent" href="node772.html">18.1.6 Examples</A>
<b class="navlabel">Next:</b>
<a class="sectref" rel="next" href="module-symbol.html">18.2 symbol  </A>
</div>
<hr /></div>
</DIV>
<!--End of Navigation Panel-->

<H3><A NAME="SECTION0020162000000000000000">
18.1.6.2 Information Discovery</A>
</H3>

<P>
Some applications benefit from direct access to the parse tree.  The
remainder of this section demonstrates how the parse tree provides
access to module documentation defined in
docstrings<a id='l2h-4957' xml:id='l2h-4957'></a> without
requiring that the code being examined be loaded into a running
interpreter via <tt class="keyword">import</tt>.  This can be very useful for
performing analyses of untrusted code.

<P>
Generally, the example will demonstrate how the parse tree may be
traversed to distill interesting information.  Two functions and a set
of classes are developed which provide programmatic access to high
level function and class definitions provided by a module.  The
classes extract information from the parse tree and provide access to
the information at a useful semantic level, one function provides a
simple low-level pattern matching capability, and the other function
defines a high-level interface to the classes by handling file
operations on behalf of the caller.  All source files mentioned here
which are not part of the Python installation are located in the
<span class="file">Demo/parser/</span> directory of the distribution.

<P>
The dynamic nature of Python allows the programmer a great deal of
flexibility, but most modules need only a limited measure of this when
defining classes, functions, and methods.  In this example, the only
definitions that will be considered are those which are defined in the
top level of their context, e.g., a function defined by a <tt class="keyword">def</tt>
statement at column zero of a module, but not a function defined
within a branch of an <tt class="keyword">if</tt> ... <tt class="keyword">else</tt> construct, though
there are some good reasons for doing so in some situations.  Nesting
of definitions will be handled by the code developed in the example.

<P>
To construct the upper-level extraction methods, we need to know what
the parse tree structure looks like and how much of it we actually
need to be concerned about.  Python uses a moderately deep parse tree
so there are a large number of intermediate nodes.  It is important to
read and understand the formal grammar used by Python.  This is
specified in the file <span class="file">Grammar/Grammar</span> in the distribution.
Consider the simplest case of interest when searching for docstrings:
a module consisting of a docstring and nothing else.  (See file
<span class="file">docstring.py</span>.)

<P>
<div class="verbatim"><pre>
"""Some documentation.
"""
</pre></div>

<P>
Using the interpreter to take a look at the parse tree, we find a
bewildering mass of numbers and parentheses, with the documentation
buried deep in nested tuples.

<P>
<div class="verbatim"><pre>
&gt;&gt;&gt; import parser
&gt;&gt;&gt; import pprint
&gt;&gt;&gt; ast = parser.suite(open('docstring.py').read())
&gt;&gt;&gt; tup = ast.totuple()
&gt;&gt;&gt; pprint.pprint(tup)
(257,
 (264,
  (265,
   (266,
    (267,
     (307,
      (287,
       (288,
        (289,
         (290,
          (292,
           (293,
            (294,
             (295,
              (296,
               (297,
                (298,
                 (299,
                  (300, (3, '"""Some documentation.\n"""'))))))))))))))))),
   (4, ''))),
 (4, ''),
 (0, ''))
</pre></div>

<P>
The numbers at the first element of each node in the tree are the node
types; they map directly to terminal and non-terminal symbols in the
grammar.  Unfortunately, they are represented as integers in the
internal representation, and the Python structures generated do not
change that.  However, the <tt class="module"><a href="module-symbol.html">symbol</a></tt> and <tt class="module"><a href="module-token.html">token</a></tt> modules
provide symbolic names for the node types and dictionaries which map
from the integers to the symbolic names for the node types.

<P>
In the output presented above, the outermost tuple contains four
elements: the integer <code>257</code> and three additional tuples.  Node
type <code>257</code> has the symbolic name <tt class="constant">file_input</tt>.  Each of
these inner tuples contains an integer as the first element; these
integers, <code>264</code>, <code>4</code>, and <code>0</code>, represent the node types
<tt class="constant">stmt</tt>, <tt class="constant">NEWLINE</tt>, and <tt class="constant">ENDMARKER</tt>,
respectively.
Note that these values may change depending on the version of Python
you are using; consult <span class="file">symbol.py</span> and <span class="file">token.py</span> for
details of the mapping.  It should be fairly clear that the outermost
node is related primarily to the input source rather than the contents
of the file, and may be disregarded for the moment.  The <tt class="constant">stmt</tt>
node is much more interesting.  In particular, all docstrings are
found in subtrees which are formed exactly as this node is formed,
with the only difference being the string itself.  The association
between the docstring in a similar tree and the defined entity (class,
function, or module) which it describes is given by the position of
the docstring subtree within the tree defining the described
structure.

<P>
By replacing the actual docstring with something to signify a variable
component of the tree, we allow a simple pattern matching approach to
check any given subtree for equivalence to the general pattern for
docstrings.  Since the example demonstrates information extraction, we
can safely require that the tree be in tuple form rather than list
form, allowing a simple variable representation to be
<code>['variable_name']</code>.  A simple recursive function can implement
the pattern matching, returning a Boolean and a dictionary of variable
name to value mappings.  (See file <span class="file">example.py</span>.)

<P>
<div class="verbatim"><pre>
from types import ListType, TupleType

def match(pattern, data, vars=None):
    if vars is None:
        vars = {}
    if type(pattern) is ListType:
        vars[pattern[0]] = data
        return 1, vars
    if type(pattern) is not TupleType:
        return (pattern == data), vars
    if len(data) != len(pattern):
        return 0, vars
    for pattern, data in map(None, pattern, data):
        same, vars = match(pattern, data, vars)
        if not same:
            break
    return same, vars
</pre></div>

<P>
Using this simple representation for syntactic variables and the symbolic
node types, the pattern for the candidate docstring subtrees becomes
fairly readable.  (See file <span class="file">example.py</span>.)

<P>
<div class="verbatim"><pre>
import symbol
import token

DOCSTRING_STMT_PATTERN = (
    symbol.stmt,
    (symbol.simple_stmt,
     (symbol.small_stmt,
      (symbol.expr_stmt,
       (symbol.testlist,
        (symbol.test,
         (symbol.and_test,
          (symbol.not_test,
           (symbol.comparison,
            (symbol.expr,
             (symbol.xor_expr,
              (symbol.and_expr,
               (symbol.shift_expr,
                (symbol.arith_expr,
                 (symbol.term,
                  (symbol.factor,
                   (symbol.power,
                    (symbol.atom,
                     (token.STRING, ['docstring'])
                     )))))))))))))))),
     (token.NEWLINE, '')
     ))
</pre></div>

<P>
Using the <tt class="function">match()</tt> function with this pattern, extracting the
module docstring from the parse tree created previously is easy:

<P>
<div class="verbatim"><pre>
&gt;&gt;&gt; found, vars = match(DOCSTRING_STMT_PATTERN, tup[1])
&gt;&gt;&gt; found
1
&gt;&gt;&gt; vars
{'docstring': '"""Some documentation.\n"""'}
</pre></div>

<P>
Once specific data can be extracted from a location where it is
expected, the question of where information can be expected
needs to be answered.  When dealing with docstrings, the answer is
fairly simple: the docstring is the first <tt class="constant">stmt</tt> node in a code
block (<tt class="constant">file_input</tt> or <tt class="constant">suite</tt> node types).  A module
consists of a single <tt class="constant">file_input</tt> node, and class and function
definitions each contain exactly one <tt class="constant">suite</tt> node.  Classes and
functions are readily identified as subtrees of code block nodes which
start with <code>(stmt, (compound_stmt, (classdef, ...</code> or
<code>(stmt, (compound_stmt, (funcdef, ...</code>.  Note that these subtrees
cannot be matched by <tt class="function">match()</tt> since it does not support multiple
sibling nodes to match without regard to number.  A more elaborate
matching function could be used to overcome this limitation, but this
is sufficient for the example.

<P>
Given the ability to determine whether a statement might be a
docstring and extract the actual string from the statement, some work
needs to be performed to walk the parse tree for an entire module and
extract information about the names defined in each context of the
module and associate any docstrings with the names.  The code to
perform this work is not complicated, but bears some explanation.

<P>
The public interface to the classes is straightforward and should
probably be somewhat more flexible.  Each ``major'' block of the
module is described by an object providing several methods for inquiry
and a constructor which accepts at least the subtree of the complete
parse tree which it represents.  The <tt class="class">ModuleInfo</tt> constructor
accepts an optional <var>name</var> parameter since it cannot
otherwise determine the name of the module.

<P>
The public classes include <tt class="class">ClassInfo</tt>, <tt class="class">FunctionInfo</tt>,
and <tt class="class">ModuleInfo</tt>.  All objects provide the
methods <tt class="method">get_name()</tt>, <tt class="method">get_docstring()</tt>,
<tt class="method">get_class_names()</tt>, and <tt class="method">get_class_info()</tt>.  The
<tt class="class">ClassInfo</tt> objects support <tt class="method">get_method_names()</tt> and
<tt class="method">get_method_info()</tt> while the other classes provide
<tt class="method">get_function_names()</tt> and <tt class="method">get_function_info()</tt>.

<P>
Within each of the forms of code block that the public classes
represent, most of the required information is in the same form and is
accessed in the same way, with classes having the distinction that
functions defined at the top level are referred to as ``methods.''
Since the difference in nomenclature reflects a real semantic
distinction from functions defined outside of a class, the
implementation needs to maintain the distinction.
Hence, most of the functionality of the public classes can be
implemented in a common base class, <tt class="class">SuiteInfoBase</tt>, with the
accessors for function and method information provided elsewhere.
Note that there is only one class which represents function and method
information; this parallels the use of the <tt class="keyword">def</tt> statement to
define both types of elements.

<P>
Most of the accessor functions are declared in <tt class="class">SuiteInfoBase</tt>
and do not need to be overridden by subclasses.  More importantly, the
extraction of most information from a parse tree is handled through a
method called by the <tt class="class">SuiteInfoBase</tt> constructor.  The example
code for most of the classes is clear when read alongside the formal
grammar, but the method which recursively creates new information
objects requires further examination.  Here is the relevant part of
the <tt class="class">SuiteInfoBase</tt> definition from <span class="file">example.py</span>:

<P>
<div class="verbatim"><pre>
class SuiteInfoBase:
    _docstring = ''
    _name = ''

    def __init__(self, tree = None):
        self._class_info = {}
        self._function_info = {}
        if tree:
            self._extract_info(tree)

    def _extract_info(self, tree):
        # extract docstring
        if len(tree) == 2:
            found, vars = match(DOCSTRING_STMT_PATTERN[1], tree[1])
        else:
            found, vars = match(DOCSTRING_STMT_PATTERN, tree[3])
        if found:
            self._docstring = eval(vars['docstring'])
        # discover inner definitions
        for node in tree[1:]:
            found, vars = match(COMPOUND_STMT_PATTERN, node)
            if found:
                cstmt = vars['compound']
                if cstmt[0] == symbol.funcdef:
                    name = cstmt[2][1]
                    self._function_info[name] = FunctionInfo(cstmt)
                elif cstmt[0] == symbol.classdef:
                    name = cstmt[2][1]
                    self._class_info[name] = ClassInfo(cstmt)
</pre></div>

<P>
After initializing some internal state, the constructor calls the
<tt class="method">_extract_info()</tt> method.  This method performs the bulk of the
information extraction which takes place in the entire example.  The
extraction has two distinct phases: the location of the docstring for
the parse tree passed in, and the discovery of additional definitions
within the code block represented by the parse tree.

<P>
The initial <tt class="keyword">if</tt> test determines whether the nested suite is of
the ``short form'' or the ``long form.''  The short form is used when
the code block is on the same line as the definition of the code
block, as in

<P>
<div class="verbatim"><pre>
def square(x): "Square an argument."; return x ** 2
</pre></div>

<P>
while the long form uses an indented block and allows nested
definitions:

<P>
<div class="verbatim"><pre>
def make_power(exp):
    "Make a function that raises an argument to the exponent `exp'."
    def raiser(x, y=exp):
        return x ** y
    return raiser
</pre></div>

<P>
When the short form is used, the code block may contain a docstring as
the first, and possibly only, <tt class="constant">small_stmt</tt> element.  The
extraction of such a docstring is slightly different and requires only
a portion of the complete pattern used in the more common case.  As
implemented, the docstring will only be found if there is only
one <tt class="constant">small_stmt</tt> node in the <tt class="constant">simple_stmt</tt> node.
Since most functions and methods which use the short form do not
provide a docstring, this may be considered sufficient.  The
extraction of the docstring proceeds using the <tt class="function">match()</tt> function
as described above, and the value of the docstring is stored as an
attribute of the <tt class="class">SuiteInfoBase</tt> object.

<P>
After docstring extraction, a simple definition discovery
algorithm operates on the <tt class="constant">stmt</tt> nodes of the
<tt class="constant">suite</tt> node.  The special case of the short form is not
tested; since there are no <tt class="constant">stmt</tt> nodes in the short form,
the algorithm will silently skip the single <tt class="constant">simple_stmt</tt>
node and correctly not discover any nested definitions.

<P>
Each statement in the code block is categorized as
a class definition, function or method definition, or
something else.  For the definition statements, the name of the
element defined is extracted and a representation object
appropriate to the definition is created with the defining subtree
passed as an argument to the constructor.  The representation objects
are stored in instance variables and may be retrieved by name using
the appropriate accessor methods.

<P>
The public classes provide any accessors required which are more
specific than those provided by the <tt class="class">SuiteInfoBase</tt> class, but
the real extraction algorithm remains common to all forms of code
blocks.  A high-level function can be used to extract the complete set
of information from a source file.  (See file <span class="file">example.py</span>.)

<P>
<div class="verbatim"><pre>
def get_docs(fileName):
    import os
    import parser

    source = open(fileName).read()
    basename = os.path.basename(os.path.splitext(fileName)[0])
    ast = parser.suite(source)
    return ModuleInfo(ast.totuple(), basename)
</pre></div>

<P>
This provides an easy-to-use interface to the documentation of a
module.  If information is required which is not extracted by the code
of this example, the code may be extended at clearly defined points to
provide additional capabilities.

<DIV CLASS="navigation">
<div class='online-navigation'>
<p></p><hr />
<table align="center" width="100%" cellpadding="0" cellspacing="2">
<tr>
<td class='online-navigation'><a rel="prev" title="18.1.6.1 Emulation of compile()"
  href="node773.html"><img src='../icons/previous.png'
  border='0' height='32'  alt='Previous Page' width='32' /></A></td>
<td class='online-navigation'><a rel="parent" title="18.1.6 Examples"
  href="node772.html"><img src='../icons/up.png'
  border='0' height='32'  alt='Up One Level' width='32' /></A></td>
<td class='online-navigation'><a rel="next" title="18.2 symbol  "
  href="module-symbol.html"><img src='../icons/next.png'
  border='0' height='32'  alt='Next Page' width='32' /></A></td>
<td align="center" width="100%">Python Library Reference</td>
<td class='online-navigation'><a rel="contents" title="Table of Contents"
  href="contents.html"><img src='../icons/contents.png'
  border='0' height='32'  alt='Contents' width='32' /></A></td>
<td class='online-navigation'><a href="modindex.html" title="Module Index"><img src='../icons/modules.png'
  border='0' height='32'  alt='Module Index' width='32' /></a></td>
<td class='online-navigation'><a rel="index" title="Index"
  href="genindex.html"><img src='../icons/index.png'
  border='0' height='32'  alt='Index' width='32' /></A></td>
</tr></table>
<div class='online-navigation'>
<b class="navlabel">Previous:</b>
<a class="sectref" rel="prev" href="node773.html">18.1.6.1 Emulation of compile()</A>
<b class="navlabel">Up:</b>
<a class="sectref" rel="parent" href="node772.html">18.1.6 Examples</A>
<b class="navlabel">Next:</b>
<a class="sectref" rel="next" href="module-symbol.html">18.2 symbol  </A>
</div>
</div>
<hr />
<span class="release-info">Release 2.4.2, documentation updated on 28 September 2005.</span>
</DIV>
<!--End of Navigation Panel-->
<ADDRESS>
See <i><a href="about.html">About this document...</a></i> for information on suggesting changes.
</ADDRESS>
</BODY>
</HTML>