| 
									
										
										
										
											1999-06-23 13:33:40 +00:00
										 |  |  | \section{\module{codeop} --- | 
					
						
							|  |  |  |          Compile Python code} | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2000-04-03 20:13:55 +00:00
										 |  |  | % LaTeXed from excellent doc-string.
 | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											1999-06-23 13:33:40 +00:00
										 |  |  | \declaremodule{standard}{codeop} | 
					
						
							| 
									
										
										
										
											2000-12-01 15:25:23 +00:00
										 |  |  | \sectionauthor{Moshe Zadka}{moshez@zadka.site.co.il} | 
					
						
							| 
									
										
										
										
											2001-08-27 20:02:17 +00:00
										 |  |  | \sectionauthor{Michael Hudson}{mwh@python.net} | 
					
						
							| 
									
										
										
										
											1999-06-23 13:33:40 +00:00
										 |  |  | \modulesynopsis{Compile (possibly incomplete) Python code.} | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2001-08-27 20:02:17 +00:00
										 |  |  | The \module{codeop} module provides utilities upon which the Python | 
					
						
							| 
									
										
										
										
											2001-08-28 14:25:03 +00: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 13:33:40 +00:00
										 |  |  | 
 | 
					
						
							| 
									
										
										
										
											2001-08-27 20:02:17 +00:00
										 |  |  | There are two parts to this job:  | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2001-08-28 14:25:03 +00: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 20:02:17 +00: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 13:33:40 +00:00
										 |  |  | 
 | 
					
						
							|  |  |  | \begin{funcdesc}{compile_command} | 
					
						
							|  |  |  |                 {source\optional{, filename\optional{, symbol}}} | 
					
						
							| 
									
										
										
										
											2000-04-03 20:13:55 +00: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 13:33:40 +00: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 20:13:55 +00:00
										 |  |  | Returns \code{None} if \var{source} is \emph{not} valid Python | 
					
						
							| 
									
										
										
										
											1999-06-23 13:33:40 +00:00
										 |  |  | code, but is a prefix of valid Python code. | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2000-04-03 20:13:55 +00: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 20:02:17 +00:00
										 |  |  | and \exception{OverflowError} or \exception{ValueError} if there is an | 
					
						
							|  |  |  | invalid literal. | 
					
						
							| 
									
										
										
										
											1999-06-23 13:33:40 +00:00
										 |  |  | 
 | 
					
						
							| 
									
										
										
										
											2000-04-03 20:13:55 +00: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 13:33:40 +00: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 20:02:17 +00:00
										 |  |  | 
 | 
					
						
							|  |  |  | \begin{classdesc}{Compile}{} | 
					
						
							| 
									
										
										
										
											2001-08-28 14:25:03 +00: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 20:02:17 +00: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 14:25:03 +00: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 20:02:17 +00: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 | 
					
						
							|  |  |  |         return compile_comamnd | 
					
						
							|  |  |  | \end{verbatim} | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | and then call \code{CommandCompiler} every time you need a fresh | 
					
						
							|  |  |  | compiler object. |