This is Info file /home/pdm/tmp/Python-1.5.2p1/Doc/lib/python-lib.info, produced by Makeinfo version 1.68 from the input file lib.texi. July 6, 1999 1.5.2  File: python-lib.info, Node: imp, Next: parser, Prev: marshal, Up: Python Services Access the `import' internals ============================= Access the implementation of the `import' statement. This module provides an interface to the mechanisms used to implement the `import' statement. It defines the following constants and functions: `get_magic()' Return the magic string value used to recognize byte-compiled code files (`.pyc' files). (This value may be different for each Python version.) `get_suffixes()' Return a list of triples, each describing a particular type of module. Each triple has the form `(SUFFIX, MODE, TYPE)', where SUFFIX is a string to be appended to the module name to form the filename to search for, MODE is the mode string to pass to the built-in `open()' function to open the file (this can be `'r'' for text files or `'rb'' for binary files), and TYPE is the file type, which has one of the values `PY_SOURCE', `PY_COMPILED', or `C_EXTENSION', described below. `find_module(name[, path])' Try to find the module NAME on the search path PATH. If PATH is a list of directory names, each directory is searched for files with any of the suffixes returned by `get_suffixes()' above. Invalid names in the list are silently ignored (but all list items must be strings). If PATH is omitted or `None', the list of directory names given by `sys.path' is searched, but first it searches a few special places: it tries to find a built-in module with the given name (`C_BUILTIN'), then a frozen module (`PY_FROZEN'), and on some systems some other places are looked in as well (on the Mac, it looks for a resource (`PY_RESOURCE'); on Windows, it looks in the registry which may point to a specific file). If search is successful, the return value is a triple `(FILE, PATHNAME, DESCRIPTION)' where FILE is an open file object positioned at the beginning, PATHNAME is the pathname of the file found, and DESCRIPTION is a triple as contained in the list returned by `get_suffixes()' describing the kind of module found. If the module does not live in a file, the returned FILE is `None', FILENAME is the empty string, and the DESCRIPTION tuple contains empty strings for its suffix and mode; the module type is as indicate in parentheses dabove. If the search is unsuccessful, `ImportError' is raised. Other exceptions indicate problems with the arguments or environment. This function does not handle hierarchical module names (names containing dots). In order to find P.M, i.e., submodule M of package P, use `find_module()' and `load_module()' to find and load package P, and then use `find_module()' with the PATH argument set to `P.__path__'. When P itself has a dotted name, apply this recipe recursively. `load_module(name, file, filename, description)' Load a module that was previously found by `find_module()' (or by an otherwise conducted search yielding compatible results). This function does more than importing the module: if the module was already imported, it is equivalent to a `reload()'! The NAME argument indicates the full module name (including the package name, if this is a submodule of a package). The FILE argument is an open file, and FILENAME is the corresponding file name; these can be `None' and `''', respectively, when the module is not being loaded from a file. The DESCRIPTION argument is a tuple as returned by `find_module()' describing what kind of module must be loaded. If the load is successful, the return value is the module object; otherwise, an exception (usually `ImportError') is raised. *Important:* the caller is responsible for closing the FILE argument, if it was not `None', even when an exception is raised. This is best done using a `try' ... `finally' statement. `new_module(name)' Return a new empty module object called NAME. This object is *not* inserted in `sys.modules'. The following constants with integer values, defined in this module, are used to indicate the search result of `find_module()'. `PY_SOURCE' The module was found as a source file. `PY_COMPILED' The module was found as a compiled code object file. `C_EXTENSION' The module was found as dynamically loadable shared library. `PY_RESOURCE' The module was found as a Macintosh resource. This value can only be returned on a Macintosh. `PKG_DIRECTORY' The module was found as a package directory. `C_BUILTIN' The module was found as a built-in module. `PY_FROZEN' The module was found as a frozen module (see `init_frozen()'). The following constant and functions are obsolete; their functionality is available through `find_module()' or `load_module()'. They are kept around for backward compatibility: `SEARCH_ERROR' Unused. `init_builtin(name)' Initialize the built-in module called NAME and return its module object. If the module was already initialized, it will be initialized *again*. A few modules cannot be initialized twice -- attempting to initialize these again will raise an `ImportError' exception. If there is no built-in module called NAME, `None' is returned. `init_frozen(name)' Initialize the frozen module called NAME and return its module object. If the module was already initialized, it will be initialized *again*. If there is no frozen module called NAME, `None' is returned. (Frozen modules are modules written in Python whose compiled byte-code object is incorporated into a custom-built Python interpreter by Python's `freeze' utility. See `Tools/freeze/' for now.) `is_builtin(name)' Return `1' if there is a built-in module called NAME which can be initialized again. Return `-1' if there is a built-in module called NAME which cannot be initialized again (see `init_builtin()'). Return `0' if there is no built-in module called NAME. `is_frozen(name)' Return `1' if there is a frozen module (see `init_frozen()') called NAME, or `0' if there is no such module. `load_compiled(name, pathname, file)' Load and initialize a module implemented as a byte-compiled code file and return its module object. If the module was already initialized, it will be initialized *again*. The NAME argument is used to create or access a module object. The PATHNAME argument points to the byte-compiled code file. The FILE argument is the byte-compiled code file, open for reading in binary mode, from the beginning. It must currently be a real file object, not a user-defined class emulating a file. `load_dynamic(name, pathname[, file])' Load and initialize a module implemented as a dynamically loadable shared library and return its module object. If the module was already initialized, it will be initialized *again*. Some modules don't like that and may raise an exception. The PATHNAME argument must point to the shared library. The NAME argument is used to construct the name of the initialization function: an external C function called `initNAME()' in the shared library is called. The optional FILE argment is ignored. (Note: using shared libraries is highly system dependent, and not all systems support it.) `load_source(name, pathname, file)' Load and initialize a module implemented as a Python source file and return its module object. If the module was already initialized, it will be initialized *again*. The NAME argument is used to create or access a module object. The PATHNAME argument points to the source file. The FILE argument is the source file, open for reading as text, from the beginning. It must currently be a real file object, not a user-defined class emulating a file. Note that if a properly matching byte-compiled file (with suffix `.pyc' or `.pyo') exists, it will be used instead of parsing the given source file. * Menu: * Examples::  File: python-lib.info, Node: Examples, Prev: imp, Up: imp Examples -------- The following function emulates what was the standard import statement up to Python 1.4 (i.e., no hierarchical module names). (This *implementation* wouldn't work in that version, since `find_module()' has been extended and `load_module()' has been added in 1.4.) import imp import sys def __import__(name, globals=None, locals=None, fromlist=None): # Fast path: see if the module has already been imported. try: return sys.modules[name] except KeyError: pass # If any of the following calls raises an exception, # there's a problem we can't handle -- let the caller handle it. fp, pathname, description = imp.find_module(name) try: return imp.load_module(name, fp, pathname, description) finally: # Since we may exit via an exception, close fp explicitly. if fp: fp.close() A more complete example that implements hierarchical module names and includes a `reload()' function can be found in the standard module `knee' (which is intended as an example only -- don't rely on any part of it being a standard interface).  File: python-lib.info, Node: parser, Next: symbol, Prev: imp, Up: Python Services Access parse trees for Python code ================================== Access parse trees for Python source code. This module was documented by Fred L. Drake, Jr. . This section was written by Fred L. Drake, Jr. . The `parser' module provides an interface to Python's internal parser and byte-code compiler. The primary purpose for this interface is to allow Python code to edit the parse tree of a Python expression and create executable code from this. This is better than trying to parse and modify an arbitrary Python code fragment as a string because parsing is performed in a manner identical to the code forming the application. It is also faster. There are a few things to note about this module which are important to making use of the data structures created. This is not a tutorial on editing the parse trees for Python code, but some examples of using the `parser' module are presented. Most importantly, a good understanding of the Python grammar processed by the internal parser is required. For full information on the language syntax, refer to the *Python Language Reference*. The parser itself is created from a grammar specification defined in the file `Grammar/Grammar' in the standard Python distribution. The parse trees stored in the AST objects created by this module are the actual output from the internal parser when created by the `expr()' or `suite()' functions, described below. The AST objects created by `sequence2ast()' faithfully simulate those structures. Be aware that the values of the sequences which are considered "correct" will vary from one version of Python to another as the formal grammar for the language is revised. However, transporting code from one Python version to another as source text will always allow correct parse trees to be created in the target version, with the only restriction being that migrating to an older version of the interpreter will not support more recent language constructs. The parse trees are not typically compatible from one version to another, whereas source code has always been forward-compatible. Each element of the sequences returned by `ast2list()' or `ast2tuple()' has a simple form. Sequences representing non-terminal elements in the grammar always have a length greater than one. The first element is an integer which identifies a production in the grammar. These integers are given symbolic names in the C header file `Include/graminit.h' and the Python module `symbol'. Each additional element of the sequence represents a component of the production as recognized in the input string: these are always sequences which have the same form as the parent. An important aspect of this structure which should be noted is that keywords used to identify the parent node type, such as the keyword `if' in an `if_stmt', are included in the node tree without any special treatment. For example, the `if' keyword is represented by the tuple `(1, 'if')', where `1' is the numeric value associated with all `NAME' tokens, including variable and function names defined by the user. In an alternate form returned when line number information is requested, the same token might be represented as `(1, 'if', 12)', where the `12' represents the line number at which the terminal symbol was found. Terminal elements are represented in much the same way, but without any child elements and the addition of the source text which was identified. The example of the `if' keyword above is representative. The various types of terminal symbols are defined in the C header file `Include/token.h' and the Python module `token'. The AST objects are not required to support the functionality of this module, but are provided for three purposes: to allow an application to amortize the cost of processing complex parse trees, to provide a parse tree representation which conserves memory space when compared to the Python list or tuple representation, and to ease the creation of additional modules in C which manipulate parse trees. A simple "wrapper" class may be created in Python to hide the use of AST objects. The `parser' module defines functions for a few distinct purposes. The most important purposes are to create AST objects and to convert AST objects to other representations such as parse trees and compiled code objects, but there are also functions which serve to query the type of parse tree represented by an AST object. See also: *Note symbol:: Useful constants representing internal nodes of the parse tree. *Note token:: Useful constants representing leaf nodes of the parse tree and functions for testing node values. * Menu: * Creating AST Objects:: * Converting AST Objects:: * Queries on AST Objects:: * Exceptions and Error Handling:: * AST Objects:: * AST Examples::  File: python-lib.info, Node: Creating AST Objects, Next: Converting AST Objects, Prev: parser, Up: parser Creating AST Objects -------------------- AST objects may be created from source code or from a parse tree. When creating an AST object from source, different functions are used to create the `'eval'' and `'exec'' forms. `expr(string)' The `expr()' function parses the parameter `STRING' as if it were an input to `compile(STRING, 'eval')'. If the parse succeeds, an AST object is created to hold the internal parse tree representation, otherwise an appropriate exception is thrown. `suite(string)' The `suite()' function parses the parameter `STRING' as if it were an input to `compile(STRING, 'exec')'. If the parse succeeds, an AST object is created to hold the internal parse tree representation, otherwise an appropriate exception is thrown. `sequence2ast(sequence)' This function accepts a parse tree represented as a sequence and builds an internal representation if possible. If it can validate that the tree conforms to the Python grammar and all nodes are valid node types in the host version of Python, an AST object is created from the internal representation and returned to the called. If there is a problem creating the internal representation, or if the tree cannot be validated, a `ParserError' exception is thrown. An AST object created this way should not be assumed to compile correctly; normal exceptions thrown by compilation may still be initiated when the AST object is passed to `compileast()'. This may indicate problems not related to syntax (such as a `MemoryError' exception), but may also be due to constructs such as the result of parsing `del f(0)', which escapes the Python parser but is checked by the bytecode compiler. Sequences representing terminal tokens may be represented as either two-element lists of the form `(1, 'name')' or as three-element lists of the form `(1, 'name', 56)'. If the third element is present, it is assumed to be a valid line number. The line number may be specified for any subset of the terminal symbols in the input tree. `tuple2ast(sequence)' This is the same function as `sequence2ast()'. This entry point is maintained for backward compatibility.  File: python-lib.info, Node: Converting AST Objects, Next: Queries on AST Objects, Prev: Creating AST Objects, Up: parser Converting AST Objects ---------------------- AST objects, regardless of the input used to create them, may be converted to parse trees represented as list- or tuple- trees, or may be compiled into executable code objects. Parse trees may be extracted with or without line numbering information. `ast2list(ast[, line_info])' This function accepts an AST object from the caller in `AST' and returns a Python list representing the equivelent parse tree. The resulting list representation can be used for inspection or the creation of a new parse tree in list form. This function does not fail so long as memory is available to build the list representation. If the parse tree will only be used for inspection, `ast2tuple()' should be used instead to reduce memory consumption and fragmentation. When the list representation is required, this function is significantly faster than retrieving a tuple representation and converting that to nested lists. If `LINE_INFO' is true, line number information will be included for all terminal tokens as a third element of the list representing the token. Note that the line number provided specifies the line on which the token *ends*. This information is omitted if the flag is false or omitted. `ast2tuple(ast[, line_info])' This function accepts an AST object from the caller in `AST' and returns a Python tuple representing the equivelent parse tree. Other than returning a tuple instead of a list, this function is identical to `ast2list()'. If `LINE_INFO' is true, line number information will be included for all terminal tokens as a third element of the list representing the token. This information is omitted if the flag is false or omitted. `compileast(ast[, filename` = '''])' The Python byte compiler can be invoked on an AST object to produce code objects which can be used as part of an `exec' statement or a call to the built-in `eval()' function. This function provides the interface to the compiler, passing the internal parse tree from `AST' to the parser, using the source file name specified by the `FILENAME' parameter. The default value supplied for `FILENAME' indicates that the source was an AST object. Compiling an AST object may result in exceptions related to compilation; an example would be a `SyntaxError' caused by the parse tree for `del f(0)': this statement is considered legal within the formal grammar for Python but is not a legal language construct. The `SyntaxError' raised for this condition is actually generated by the Python byte-compiler normally, which is why it can be raised at this point by the `parser' module. Most causes of compilation failure can be diagnosed programmatically by inspection of the parse tree.  File: python-lib.info, Node: Queries on AST Objects, Next: Exceptions and Error Handling, Prev: Converting AST Objects, Up: parser Queries on AST Objects ---------------------- Two functions are provided which allow an application to determine if an AST was created as an expression or a suite. Neither of these functions can be used to determine if an AST was created from source code via `expr()' or `suite()' or from a parse tree via `sequence2ast()'. `isexpr(ast)' When `AST' represents an `'eval'' form, this function returns true, otherwise it returns false. This is useful, since code objects normally cannot be queried for this information using existing built-in functions. Note that the code objects created by `compileast()' cannot be queried like this either, and are identical to those created by the built-in `compile()' function. `issuite(ast)' This function mirrors `isexpr()' in that it reports whether an AST object represents an `'exec'' form, commonly known as a "suite." It is not safe to assume that this function is equivelent to `not isexpr(AST)', as additional syntactic fragments may be supported in the future.  File: python-lib.info, Node: Exceptions and Error Handling, Next: AST Objects, Prev: Queries on AST Objects, Up: parser Exceptions and Error Handling ----------------------------- The parser module defines a single exception, but may also pass other built-in exceptions from other portions of the Python runtime environment. See each function for information about the exceptions it can raise. `ParserError' Exception raised when a failure occurs within the parser module. This is generally produced for validation failures rather than the built in `SyntaxError' thrown during normal parsing. The exception argument is either a string describing the reason of the failure or a tuple containing a sequence causing the failure from a parse tree passed to `sequence2ast()' and an explanatory string. Calls to `sequence2ast()' need to be able to handle either type of exception, while calls to other functions in the module will only need to be aware of the simple string values. Note that the functions `compileast()', `expr()', and `suite()' may throw exceptions which are normally thrown by the parsing and compilation process. These include the built in exceptions `MemoryError', `OverflowError', `SyntaxError', and `SystemError'. In these cases, these exceptions carry all the meaning normally associated with them. Refer to the descriptions of each function for detailed information.  File: python-lib.info, Node: AST Objects, Next: AST Examples, Prev: Exceptions and Error Handling, Up: parser AST Objects ----------- AST objects returned by `expr()', `suite()' and `sequence2ast()' have no methods of their own. Ordered and equality comparisons are supported between AST objects. Pickling of AST objects (using the `pickle' module) is also supported. `ASTType' The type of the objects returned by `expr()', `suite()' and `sequence2ast()'. AST objects have the following methods: `compile([filename])' Same as `compileast(AST, FILENAME)'. `isexpr()' Same as `isexpr(AST)'. `issuite()' Same as `issuite(AST)'. `tolist([line_info])' Same as `ast2list(AST, LINE_INFO)'. `totuple([line_info])' Same as `ast2tuple(AST, LINE_INFO)'.  File: python-lib.info, Node: AST Examples, Prev: AST Objects, Up: parser Examples -------- The parser modules allows operations to be performed on the parse tree of Python source code before the bytecode is generated, and provides for inspection of the parse tree for information gathering purposes. Two examples are presented. The simple example demonstrates emulation of the `compile()' built-in function and the complex example shows the use of a parse tree for information discovery. * Menu: * Emulation of compile:: * Information Discovery::  File: python-lib.info, Node: Emulation of compile, Next: Information Discovery, Prev: AST Examples, Up: AST Examples Emulation of `compile()' ........................ While many useful operations may take place between parsing and bytecode generation, the simplest operation is to do nothing. For this purpose, using the `parser' module to produce an intermediate data structure is equivelent to the code >>> code = compile('a + 5', 'eval') >>> a = 5 >>> eval(code) 10 The equivelent operation using the `parser' module is somewhat longer, and allows the intermediate internal parse tree to be retained as an AST object: >>> import parser >>> ast = parser.expr('a + 5') >>> code = parser.compileast(ast) >>> a = 5 >>> eval(code) 10 An application which needs both AST and code objects can package this code into readily available functions: import parser def load_suite(source_string): ast = parser.suite(source_string) code = parser.compileast(ast) return ast, code def load_expression(source_string): ast = parser.expr(source_string) code = parser.compileast(ast) return ast, code  File: python-lib.info, Node: Information Discovery, Prev: Emulation of compile, Up: AST Examples Information Discovery ..................... 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 without requiring that the code being examined be loaded into a running interpreter via `import'. This can be very useful for performing analyses of untrusted code. 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 `Demo/parser/' directory of the distribution. 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 `def' statement at column zero of a module, but not a function defined within a branch of an `if' ... `else' 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. 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 `Grammar/Grammar' in the distribution. Consider the simplest case of interest when searching for docstrings: a module consisting of a docstring and nothing else. (See file `docstring.py'.) """Some documentation. """ 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. >>> import parser >>> import pprint >>> ast = parser.suite(open('docstring.py').read()) >>> tup = parser.ast2tuple(ast) >>> 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.\012"""'))))))))))))))))), (4, ''))), (4, ''), (0, '')) 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 `symbol' and `token' modules provide symbolic names for the node types and dictionaries which map from the integers to the symbolic names for the node types. In the output presented above, the outermost tuple contains four elements: the integer `257' and three additional tuples. Node type `257' has the symbolic name `file_input'. Each of these inner tuples contains an integer as the first element; these integers, `264', `4', and `0', represent the node types `stmt', `NEWLINE', and `ENDMARKER', respectively. Note that these values may change depending on the version of Python you are using; consult `symbol.py' and `token.py' 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 `stmt' 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. 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 equivelence 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 `['variable_name']'. A simple recursive function can implement the pattern matching, returning a boolean and a dictionary of variable name to value mappings. (See file `example.py'.) 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 Using this simple representation for syntactic variables and the symbolic node types, the pattern for the candidate docstring subtrees becomes fairly readable. (See file `example.py'.) 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, '') )) Using the `match()' function with this pattern, extracting the module docstring from the parse tree created previously is easy: >>> found, vars = match(DOCSTRING_STMT_PATTERN, tup[1]) >>> found 1 >>> vars {'docstring': '"""Some documentation.\012"""'} 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 `stmt' node in a code block (`file_input' or `suite' node types). A module consists of a single `file_input' node, and class and function definitions each contain exactly one `suite' node. Classes and functions are readily identified as subtrees of code block nodes which start with `(stmt, (compound_stmt, (classdef, ...' or `(stmt, (compound_stmt, (funcdef, ...'. Note that these subtrees cannot be matched by `match()' 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. 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. 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 `ModuleInfo' constructor accepts an optional NAME parameter since it cannot otherwise determine the name of the module. The public classes include `ClassInfo', `FunctionInfo', and `ModuleInfo'. All objects provide the methods `get_name()', `get_docstring()', `get_class_names()', and `get_class_info()'. The `ClassInfo' objects support `get_method_names()' and `get_method_info()' while the other classes provide `get_function_names()' and `get_function_info()'. 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, `SuiteInfoBase', 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 `def' statement to define both types of elements. Most of the accessor functions are declared in `SuiteInfoBase' and do not need to be overriden by subclasses. More importantly, the extraction of most information from a parse tree is handled through a method called by the `SuiteInfoBase' 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 `SuiteInfoBase' definition from `example.py': 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) After initializing some internal state, the constructor calls the `_extract_info()' 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. The initial `if' 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 def square(x): "Square an argument."; return x ** 2 while the long form uses an indented block and allows nested definitions: 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 When the short form is used, the code block may contain a docstring as the first, and possibly only, `small_stmt' 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 `small_stmt' node in the `simple_stmt' 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 `match()' function as described above, and the value of the docstring is stored as an attribute of the `SuiteInfoBase' object. After docstring extraction, a simple definition discovery algorithm operates on the `stmt' nodes of the `suite' node. The special case of the short form is not tested; since there are no `stmt' nodes in the short form, the algorithm will silently skip the single `simple_stmt' node and correctly not discover any nested definitions. 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 repesentation objects are stored in instance variables and may be retrieved by name using the appropriate accessor methods. The public classes provide any accessors required which are more specific than those provided by the `SuiteInfoBase' 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 `example.py'.) def get_docs(fileName): source = open(fileName).read() import os basename = os.path.basename(os.path.splitext(fileName)[0]) import parser ast = parser.suite(source) tup = parser.ast2tuple(ast) return ModuleInfo(tup, basename) 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.  File: python-lib.info, Node: symbol, Next: token, Prev: parser, Up: Python Services Constants used with Python parse trees ====================================== Constants representing internal nodes of the parse tree. This section was written by Fred L. Drake, Jr. . This module provides constants which represent the numeric values of internal nodes of the parse tree. Unlike most Python constants, these use lower-case names. Refer to the file `Grammar/Grammar' in the Python distribution for the defintions of the names in the context of the language grammar. The specific numeric values which the names map to may change between Python versions. This module also provides one additional data object: `sym_name' Dictionary mapping the numeric values of the constants defined in this module back to name strings, allowing more human-readable representation of parse trees to be generated. See also: *Note parser:: second example uses this module  File: python-lib.info, Node: token, Next: keyword, Prev: symbol, Up: Python Services Constants used with Python parse trees ====================================== Constants representing terminal nodes of the parse tree. This section was written by Fred L. Drake, Jr. . This module provides constants which represent the numeric values of leaf nodes of the parse tree (terminal tokens). Refer to the file `Grammar/Grammar' in the Python distribution for the defintions of the names in the context of the language grammar. The specific numeric values which the names map to may change between Python versions. This module also provides one data object and some functions. The functions mirror definitions in the Python C header files. `tok_name' Dictionary mapping the numeric values of the constants defined in this module back to name strings, allowing more human-readable representation of parse trees to be generated. `ISTERMINAL(x)' Return true for terminal token values. `ISNONTERMINAL(x)' Return true for non-terminal token values. `ISEOF(x)' Return true if X is the marker indicating the end of input. See also: *Note parser:: second example uses this module  File: python-lib.info, Node: keyword, Next: tokenize, Prev: token, Up: Python Services Testing for Python keywords =========================== Test whether a string is a keyword in Python. This module allows a Python program to determine if a string is a keyword. A single function is provided: `iskeyword(s)' Return true if S is a Python keyword.  File: python-lib.info, Node: tokenize, Next: pyclbr, Prev: keyword, Up: Python Services Tokenizer for Python source =========================== Lexical scanner for Python source code. This module was documented by Ka Ping Yee <>. This section was written by Fred L. Drake, Jr. . The `tokenize' module provides a lexical scanner for Python source code, implemented in Python. The scanner in this module returns comments as tokens as well, making it useful for implementing "pretty-printers," including colorizers for on-screen displays. The scanner is exposed by a single function: `tokenize(readline[, tokeneater])' The `tokenize()' function accepts two parameters: one representing the input stream, and one providing an output mechanism for `tokenize()'. The first parameter, READLINE, must be a callable object which provides the same interface as the `readline()' method of built-in file objects (see section~*Note File Objectsfile::). Each call to the function should return one line of input as a string. The second parameter, TOKENEATER, must also be a callable object. It is called with five parameters: the token type, the token string, a tuple `(SROW, SCOL)' specifying the row and column where the token begins in the source, a tuple `(EROW, ECOL)' giving the ending position of the token, and the line on which the token was found. The line passed is the *logical* line; continuation lines are included. All constants from the `token' module are also exported from `tokenize', as is one additional token type value that might be passed to the TOKENEATER function by `tokenize()': `COMMENT' Token value used to indicate a comment.  File: python-lib.info, Node: pyclbr, Next: code, Prev: tokenize, Up: Python Services Python class browser support ============================ Supports information extraction for a Python class browser. This section was written by Fred L. Drake, Jr. . The `pyclbr' can be used to determine some limited information about the classes and methods defined in a module. The information provided is sufficient to implement a traditional three-pane class browser. The information is extracted from the source code rather than from an imported module, so this module is safe to use with untrusted source code. This restriction makes it impossible to use this module with modules not implemented in Python, including many standard and optional extension modules. `readmodule(module[, path])' Read a module and return a dictionary mapping class names to class descriptor objects. The parameter MODULE should be the name of a module as a string; it may be the name of a module within a package. The PATH parameter should be a sequence, and is used to augment the value of `sys.path', which is used to locate module source code. * Menu: * Class Descriptor Objects::  File: python-lib.info, Node: Class Descriptor Objects, Prev: pyclbr, Up: pyclbr Class Descriptor Objects ------------------------ The class descriptor objects used as values in the dictionary returned by `readmodule()' provide the following data members: `module' The name of the module defining the class described by the class descriptor. `name' The name of the class. `super' A list of class descriptors which describe the immediate base classes of the class being described. Classes which are named as superclasses but which are not discoverable by `readmodule()' are listed as a string with the class name instead of class descriptors. `methods' A dictionary mapping method names to line numbers. `file' Name of the file containing the class statement defining the class. `lineno' The line number of the class statement within the file named by `file'.  File: python-lib.info, Node: code, Next: codeop, Prev: pyclbr, Up: Python Services Code object services. ===================== Code object services. The `code' module defines operations pertaining to Python code objects. It defines the following function: `compile_command(source, [filename[, symbol]])' This function is useful for programs that want to emulate Python's interpreter main loop (a.k.a. the read-eval-print loop). The tricky part is to determine when the user has entered an incomplete command that can be completed by entering more text (as opposed to a complete command or a syntax error). This function *almost* always makes the same decision as the real interpreter main loop. Arguments: SOURCE is the source string; FILENAME is the optional filename from which source was read, defaulting to `'''; and SYMBOL is the optional grammar start symbol, which should be either `'single'' (the default) or `'eval''. Return a code object (the same as `compile(SOURCE, FILENAME, SYMBOL)') if the command is complete and valid; return `None' if the command is incomplete; raise `SyntaxError' if the command is a syntax error.  File: python-lib.info, Node: codeop, Next: pprint, Prev: code, Up: Python Services Compile Python code =================== This section was written by Moshe Zadka . Compile (possibly incomplete) Python code. The `codeop' module provides a function to compile Python code with hints on whether it certainly complete, possible complete or definitely incomplete. This is used by the `code' module and should not normally be used directly. The `codeop' module defines the following function: `compile_command(source[, filename[, symbol]])' Try to compile SOURCE, which should be a string of Python code. Return a code object if SOURCE is valid Python code. In that case, the filename attribute of the code object will be FILENAME, which defaults to `'''. Return `None' if SOURCE is *not* valid Python code, but is a prefix of valid Python code. Raise an exception if there is a problem with SOURCE: * `SyntaxError' if there is invalid Python syntax. * `OverflowError' if there is an invalid numeric constant. The SYMBOL argument means whether to compile it as a statement (`'single'', the default) or as an expression (`'eval''). *Caveat:* It is possible (but not likely) that the parser stops parsing with a successful outcome before reaching the end of the source; in this case, trailing symbols may be ignored instead of causing an error. For example, a backslash followed by two newlines may be followed by arbitrary garbage. This will be fixed once the API for the parser is better.