| :mod:`parser` --- Access Python parse trees | |
| =========================================== | |
| .. module:: parser | |
| :synopsis: Access parse trees for Python source code. | |
| .. moduleauthor:: Fred L. Drake, Jr. <fdrake@acm.org> | |
| .. sectionauthor:: Fred L. Drake, Jr. <fdrake@acm.org> | |
| .. Copyright 1995 Virginia Polytechnic Institute and State University and Fred | |
| L. Drake, Jr. This copyright notice must be distributed on all copies, but | |
| this document otherwise may be distributed as part of the Python | |
| distribution. No fee may be charged for this document in any representation, | |
| either on paper or electronically. This restriction does not affect other | |
| elements in a distributed package in any way. | |
| .. index:: single: parsing; Python source code | |
| The :mod:`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. | |
| .. note:: | |
| From Python 2.5 onward, it's much more convenient to cut in at the Abstract | |
| Syntax Tree (AST) generation and compilation stage, using the :mod:`ast` | |
| module. | |
| The :mod:`parser` module exports the names documented here also with "st" | |
| replaced by "ast"; this is a legacy from the time when there was no other | |
| AST and has nothing to do with the AST found in Python 2.5. This is also the | |
| reason for the functions' keyword arguments being called *ast*, not *st*. | |
| The "ast" functions have been removed in Python 3. | |
| 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 :mod:`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 :ref:`reference-index`. The parser | |
| itself is created from a grammar specification defined in the file | |
| :file:`Grammar/Grammar` in the standard Python distribution. The parse trees | |
| stored in the ST objects created by this module are the actual output from the | |
| internal parser when created by the :func:`expr` or :func:`suite` functions, | |
| described below. The ST objects created by :func:`sequence2st` 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 :func:`st2list` or :func:`st2tuple` | |
| 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 :file:`Include/graminit.h` and the Python module | |
| :mod:`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 :keyword:`if` in an :const:`if_stmt`, are included in the | |
| node tree without any special treatment. For example, the :keyword:`if` keyword | |
| is represented by the tuple ``(1, 'if')``, where ``1`` is the numeric value | |
| associated with all :const:`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 :keyword:`if` keyword above is representative. The various types of | |
| terminal symbols are defined in the C header file :file:`Include/token.h` and | |
| the Python module :mod:`token`. | |
| The ST 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 ST objects. | |
| The :mod:`parser` module defines functions for a few distinct purposes. The | |
| most important purposes are to create ST objects and to convert ST 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 | |
| ST object. | |
| .. seealso:: | |
| Module :mod:`symbol` | |
| Useful constants representing internal nodes of the parse tree. | |
| Module :mod:`token` | |
| Useful constants representing leaf nodes of the parse tree and functions for | |
| testing node values. | |
| .. _creating-sts: | |
| Creating ST Objects | |
| ------------------- | |
| ST objects may be created from source code or from a parse tree. When creating | |
| an ST object from source, different functions are used to create the ``'eval'`` | |
| and ``'exec'`` forms. | |
| .. function:: expr(source) | |
| The :func:`expr` function parses the parameter *source* as if it were an input | |
| to ``compile(source, 'file.py', 'eval')``. If the parse succeeds, an ST object | |
| is created to hold the internal parse tree representation, otherwise an | |
| appropriate exception is raised. | |
| .. function:: suite(source) | |
| The :func:`suite` function parses the parameter *source* as if it were an input | |
| to ``compile(source, 'file.py', 'exec')``. If the parse succeeds, an ST object | |
| is created to hold the internal parse tree representation, otherwise an | |
| appropriate exception is raised. | |
| .. function:: sequence2st(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 ST 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 :exc:`ParserError` exception is raised. An | |
| ST object created this way should not be assumed to compile correctly; normal | |
| exceptions raised by compilation may still be initiated when the ST object is | |
| passed to :func:`compilest`. This may indicate problems not related to syntax | |
| (such as a :exc:`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. | |
| .. function:: tuple2st(sequence) | |
| This is the same function as :func:`sequence2st`. This entry point is | |
| maintained for backward compatibility. | |
| .. _converting-sts: | |
| Converting ST Objects | |
| --------------------- | |
| ST 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. | |
| .. function:: st2list(ast[, line_info]) | |
| This function accepts an ST object from the caller in *ast* and returns a | |
| Python list representing the equivalent 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, | |
| :func:`st2tuple` 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. | |
| .. function:: st2tuple(ast[, line_info]) | |
| This function accepts an ST object from the caller in *ast* and returns a | |
| Python tuple representing the equivalent parse tree. Other than returning a | |
| tuple instead of a list, this function is identical to :func:`st2list`. | |
| 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. | |
| .. function:: compilest(ast, filename='<syntax-tree>') | |
| .. index:: builtin: eval | |
| The Python byte compiler can be invoked on an ST object to produce code objects | |
| which can be used as part of an :keyword:`exec` statement or a call to the | |
| built-in :func:`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 ST object. | |
| Compiling an ST object may result in exceptions related to compilation; an | |
| example would be a :exc:`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 :exc:`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 :mod:`parser` module. Most causes of | |
| compilation failure can be diagnosed programmatically by inspection of the parse | |
| tree. | |
| .. _querying-sts: | |
| Queries on ST Objects | |
| --------------------- | |
| Two functions are provided which allow an application to determine if an ST was | |
| created as an expression or a suite. Neither of these functions can be used to | |
| determine if an ST was created from source code via :func:`expr` or | |
| :func:`suite` or from a parse tree via :func:`sequence2st`. | |
| .. function:: isexpr(ast) | |
| .. index:: builtin: compile | |
| 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 :func:`compilest` cannot be queried like this either, and | |
| are identical to those created by the built-in :func:`compile` function. | |
| .. function:: issuite(ast) | |
| This function mirrors :func:`isexpr` in that it reports whether an ST object | |
| represents an ``'exec'`` form, commonly known as a "suite." It is not safe to | |
| assume that this function is equivalent to ``not isexpr(ast)``, as additional | |
| syntactic fragments may be supported in the future. | |
| .. _st-errors: | |
| 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. | |
| .. exception:: ParserError | |
| Exception raised when a failure occurs within the parser module. This is | |
| generally produced for validation failures rather than the built-in | |
| :exc:`SyntaxError` raised 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 :func:`sequence2st` | |
| and an explanatory string. Calls to :func:`sequence2st` 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 :func:`compilest`, :func:`expr`, and :func:`suite` may | |
| raise exceptions which are normally raised by the parsing and compilation | |
| process. These include the built in exceptions :exc:`MemoryError`, | |
| :exc:`OverflowError`, :exc:`SyntaxError`, and :exc:`SystemError`. In these | |
| cases, these exceptions carry all the meaning normally associated with them. | |
| Refer to the descriptions of each function for detailed information. | |
| .. _st-objects: | |
| ST Objects | |
| ---------- | |
| Ordered and equality comparisons are supported between ST objects. Pickling of | |
| ST objects (using the :mod:`pickle` module) is also supported. | |
| .. data:: STType | |
| The type of the objects returned by :func:`expr`, :func:`suite` and | |
| :func:`sequence2st`. | |
| ST objects have the following methods: | |
| .. method:: ST.compile([filename]) | |
| Same as ``compilest(st, filename)``. | |
| .. method:: ST.isexpr() | |
| Same as ``isexpr(st)``. | |
| .. method:: ST.issuite() | |
| Same as ``issuite(st)``. | |
| .. method:: ST.tolist([line_info]) | |
| Same as ``st2list(st, line_info)``. | |
| .. method:: ST.totuple([line_info]) | |
| Same as ``st2tuple(st, line_info)``. | |
| Example: Emulation of :func:`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 :mod:`parser` module to produce an intermediate data structure is equivalent | |
| to the code :: | |
| >>> code = compile('a + 5', 'file.py', 'eval') | |
| >>> a = 5 | |
| >>> eval(code) | |
| 10 | |
| The equivalent operation using the :mod:`parser` module is somewhat longer, and | |
| allows the intermediate internal parse tree to be retained as an ST object:: | |
| >>> import parser | |
| >>> st = parser.expr('a + 5') | |
| >>> code = st.compile('file.py') | |
| >>> a = 5 | |
| >>> eval(code) | |
| 10 | |
| An application which needs both ST and code objects can package this code into | |
| readily available functions:: | |
| import parser | |
| def load_suite(source_string): | |
| st = parser.suite(source_string) | |
| return st, st.compile() | |
| def load_expression(source_string): | |
| st = parser.expr(source_string) | |
| return st, st.compile() |