1999-06-23 10:33:40 -03:00
|
|
|
\section{\module{codeop} ---
|
|
|
|
Compile Python code}
|
|
|
|
|
2000-04-03 17:13:55 -03:00
|
|
|
% LaTeXed from excellent doc-string.
|
|
|
|
|
1999-06-23 10:33:40 -03:00
|
|
|
\declaremodule{standard}{codeop}
|
2000-12-01 11:25:23 -04:00
|
|
|
\sectionauthor{Moshe Zadka}{moshez@zadka.site.co.il}
|
2001-08-27 17:02:17 -03:00
|
|
|
\sectionauthor{Michael Hudson}{mwh@python.net}
|
1999-06-23 10:33:40 -03:00
|
|
|
\modulesynopsis{Compile (possibly incomplete) Python code.}
|
|
|
|
|
2001-08-27 17:02:17 -03:00
|
|
|
The \module{codeop} module provides utilities upon which the Python
|
2001-08-28 11:25:03 -03:00
|
|
|
read-eval-print loop can be emulated, as is done in the
|
|
|
|
\refmodule{code} module. As a result, you probably don't want to use
|
|
|
|
the module directly; if you want to include such a loop in your
|
|
|
|
program you probably want to use the \refmodule{code} module instead.
|
1999-06-23 10:33:40 -03:00
|
|
|
|
2001-08-27 17:02:17 -03:00
|
|
|
There are two parts to this job:
|
|
|
|
|
2001-08-28 11:25:03 -03:00
|
|
|
\begin{enumerate}
|
|
|
|
\item Being able to tell if a line of input completes a Python
|
|
|
|
statement: in short, telling whether to print
|
|
|
|
`\code{>\code{>}>~} or `\code{...~}' next.
|
|
|
|
\item Remembering which future statements the user has entered, so
|
|
|
|
subsequent input can be compiled with these in effect.
|
|
|
|
\end{enumerate}
|
2001-08-27 17:02:17 -03:00
|
|
|
|
|
|
|
The \module{codeop} module provides a way of doing each of these
|
|
|
|
things, and a way of doing them both.
|
|
|
|
|
|
|
|
To do just the former:
|
1999-06-23 10:33:40 -03:00
|
|
|
|
|
|
|
\begin{funcdesc}{compile_command}
|
|
|
|
{source\optional{, filename\optional{, symbol}}}
|
2000-04-03 17:13:55 -03:00
|
|
|
Tries to compile \var{source}, which should be a string of Python
|
|
|
|
code and return a code object if \var{source} is valid
|
1999-06-23 10:33:40 -03:00
|
|
|
Python code. In that case, the filename attribute of the code object
|
|
|
|
will be \var{filename}, which defaults to \code{'<input>'}.
|
2000-04-03 17:13:55 -03:00
|
|
|
Returns \code{None} if \var{source} is \emph{not} valid Python
|
1999-06-23 10:33:40 -03:00
|
|
|
code, but is a prefix of valid Python code.
|
|
|
|
|
2000-04-03 17:13:55 -03:00
|
|
|
If there is a problem with \var{source}, an exception will be raised.
|
|
|
|
\exception{SyntaxError} is raised if there is invalid Python syntax,
|
2001-08-27 17:02:17 -03:00
|
|
|
and \exception{OverflowError} or \exception{ValueError} if there is an
|
|
|
|
invalid literal.
|
1999-06-23 10:33:40 -03:00
|
|
|
|
2000-04-03 17:13:55 -03:00
|
|
|
The \var{symbol} argument determines whether \var{source} is compiled
|
|
|
|
as a statement (\code{'single'}, the default) or as an expression
|
|
|
|
(\code{'eval'}). Any other value will cause \exception{ValueError} to
|
|
|
|
be raised.
|
1999-06-23 10:33:40 -03:00
|
|
|
|
|
|
|
\strong{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.
|
|
|
|
\end{funcdesc}
|
2001-08-27 17:02:17 -03:00
|
|
|
|
|
|
|
\begin{classdesc}{Compile}{}
|
2001-08-28 11:25:03 -03:00
|
|
|
Instances of this class have \method{__call__()} methods indentical in
|
|
|
|
signature to the built-in function \function{compile()}, but with the
|
2001-08-27 17:02:17 -03:00
|
|
|
difference that if the instance compiles program text containing a
|
|
|
|
\module{__future__} statement, the instance 'remembers' and compiles
|
|
|
|
all subsequent program texts with the statement in force.
|
|
|
|
\end{classdesc}
|
|
|
|
|
|
|
|
\begin{classdesc}{CommandCompiler}{}
|
2001-08-28 11:25:03 -03:00
|
|
|
Instances of this class have \method{__call__()} methods identical in
|
|
|
|
signature to \function{compile_command()}; the difference is that if
|
|
|
|
the instance compiles program text containing a \code{__future__}
|
2001-08-27 17:02:17 -03:00
|
|
|
statement, the instance 'remembers' and compiles all subsequent
|
|
|
|
program texts with the statement in force.
|
|
|
|
\end{classdesc}
|
|
|
|
|
|
|
|
A note on version compatibility: the \class{Compile} and
|
|
|
|
\class{CommandCompiler} are new in Python 2.2. If you want to enable
|
|
|
|
the future-tracking features of 2.2 but also retain compatibility with
|
|
|
|
2.1 and earlier versions of Python you can either write
|
|
|
|
|
|
|
|
\begin{verbatim}
|
|
|
|
try:
|
|
|
|
from codeop import CommandCompiler
|
|
|
|
compile_command = CommandCompiler()
|
|
|
|
del CommandCompiler
|
|
|
|
except ImportError:
|
|
|
|
from codeop import compile_command
|
|
|
|
\end{verbatim}
|
|
|
|
|
|
|
|
which is a low-impact change, but introduces possibly unwanted global
|
|
|
|
state into your program, or you can write:
|
|
|
|
|
|
|
|
\begin{verbatim}
|
|
|
|
try:
|
|
|
|
from codeop import CommandCompiler
|
|
|
|
except ImportError:
|
|
|
|
def CommandCompiler():
|
|
|
|
from codeop import compile_command
|
2002-09-04 12:12:07 -03:00
|
|
|
return compile_command
|
2001-08-27 17:02:17 -03:00
|
|
|
\end{verbatim}
|
|
|
|
|
|
|
|
and then call \code{CommandCompiler} every time you need a fresh
|
|
|
|
compiler object.
|