[Python-checkins] CVS: python/dist/src/Doc/lib libcode.tex,1.12,1.13 libcodeop.tex,1.3,1.4 libfuncs.tex,1.81,1.82

Michael Hudson mwh@users.sourceforge.net
Mon, 27 Aug 2001 13:02:19 -0700


Update of /cvsroot/python/python/dist/src/Doc/lib
In directory usw-pr-cvs1:/tmp/cvs-serv30254/lib

Modified Files:
	libcode.tex libcodeop.tex libfuncs.tex 
Log Message:
Docs for the PEP 264 changes.



Index: libcode.tex
===================================================================
RCS file: /cvsroot/python/python/dist/src/Doc/lib/libcode.tex,v
retrieving revision 1.12
retrieving revision 1.13
diff -C2 -d -r1.12 -r1.13
*** libcode.tex	2000/09/14 20:42:53	1.12
--- libcode.tex	2001/08/27 20:02:16	1.13
***************
*** 61,67 ****
  valid; \code{None} if the command is incomplete; raises
  \exception{SyntaxError} if the command is complete and contains a
! syntax error, or raises \exception{OverflowError} if the command
! includes a numeric constant which exceeds the range of the
! appropriate numeric type.
  \end{funcdesc}
  
--- 61,66 ----
  valid; \code{None} if the command is incomplete; raises
  \exception{SyntaxError} if the command is complete and contains a
! syntax error, or raises \exception{OverflowError} or
! \exception{ValueError} if the command cotains an invalid literal.
  \end{funcdesc}
  

Index: libcodeop.tex
===================================================================
RCS file: /cvsroot/python/python/dist/src/Doc/lib/libcodeop.tex,v
retrieving revision 1.3
retrieving revision 1.4
diff -C2 -d -r1.3 -r1.4
*** libcodeop.tex	2000/12/01 15:25:23	1.3
--- libcodeop.tex	2001/08/27 20:02:16	1.4
***************
*** 6,18 ****
  \declaremodule{standard}{codeop}
  \sectionauthor{Moshe Zadka}{moshez@zadka.site.co.il}
  \modulesynopsis{Compile (possibly incomplete) Python code.}
  
! The \module{codeop} module provides a function to compile Python code
! with hints on whether it is certainly complete, possibly complete or
! definitely incomplete.  This is used by the \refmodule{code} module
! and should not normally be used directly.
  
! The \module{codeop} module defines the following function:
  
  \begin{funcdesc}{compile_command}
                  {source\optional{, filename\optional{, symbol}}}
--- 6,33 ----
  \declaremodule{standard}{codeop}
  \sectionauthor{Moshe Zadka}{moshez@zadka.site.co.il}
+ \sectionauthor{Michael Hudson}{mwh@python.net}
  \modulesynopsis{Compile (possibly incomplete) Python code.}
  
! The \module{codeop} module provides utilities upon which the Python
! read-eval-print loop can be emulated -- as 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} instead.
  
! There are two parts to this job: 
  
+ \begin{list}
+ \listitem Being able to tell if a line of input completes a Python 
+           statement -- in short telling whether to print ``>>> '' or
+           ``... '' next.
+ \listitem Remembering which future statements the user has entered, so 
+           subsequent input can be compiled wiht these in effect.
+ \end{list}
+ 
+ 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:
+ 
  \begin{funcdesc}{compile_command}
                  {source\optional{, filename\optional{, symbol}}}
***************
*** 26,31 ****
  If there is a problem with \var{source}, an exception will be raised.
  \exception{SyntaxError} is raised if there is invalid Python syntax,
! and \exception{OverflowError} if there is an invalid numeric
! constant.
  
  The \var{symbol} argument determines whether \var{source} is compiled
--- 41,46 ----
  If there is a problem with \var{source}, an exception will be raised.
  \exception{SyntaxError} is raised if there is invalid Python syntax,
! and \exception{OverflowError} or \exception{ValueError} if there is an
! invalid literal.
  
  The \var{symbol} argument determines whether \var{source} is compiled
***************
*** 42,43 ****
--- 57,103 ----
  for the parser is better.
  \end{funcdesc}
+ 
+ \begin{classdesc}{Compile}{}
+ Instances of this class have \method{__call__} methods indentical in
+ signature to the built-in function \function{compile}, but with the
+ 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}{}
+ 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 \method{__future__}
+ 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.

Index: libfuncs.tex
===================================================================
RCS file: /cvsroot/python/python/dist/src/Doc/lib/libfuncs.tex,v
retrieving revision 1.81
retrieving revision 1.82
diff -C2 -d -r1.81 -r1.82
*** libfuncs.tex	2001/07/26 20:02:17	1.81
--- libfuncs.tex	2001/08/27 20:02:16	1.82
***************
*** 119,123 ****
  \end{funcdesc}
  
! \begin{funcdesc}{compile}{string, filename, kind}
    Compile the \var{string} into a code object.  Code objects can be
    executed by an \keyword{exec} statement or evaluated by a call to
--- 119,124 ----
  \end{funcdesc}
  
! \begin{funcdesc}{compile}{string, filename, kind\optional{, 
!                           flags\optional{, dont_inherit}}}
    Compile the \var{string} into a code object.  Code objects can be
    executed by an \keyword{exec} statement or evaluated by a call to
***************
*** 131,134 ****
--- 132,153 ----
    interactive statement (in the latter case, expression statements
    that evaluate to something else than \code{None} will printed).
+ 
+   The optional arguments \var{flags} and \optional{dont_inherit}
+   (which are new in Python 2.2) control which future statements (see
+   \pep{236}) affect the compilation of \var{string}.  If neither is
+   present (or both are zero) the code is compiled with those future
+   statements that are in effect in the code that is calling compile.
+   If the \var{flags} argument is given and \var{dont_inherit} is not
+   (or is zero) then the future statements specified by the \var{flags}
+   argument are used in addition to those that would be used anyway.
+   If \var{dont_inherit} is a non-zero integer then the \var{flags}
+   argument is it -- the future statements in effect around the call to
+   compile are ignored.
+ 
+   Future statemants are specified by bits which can be bitwise or-ed
+   together to specify multiple statements.  The bitfield required to
+   specify a given feature can be found as the \member{compiler_flag}
+   attribute on the \class{_Feature} instance in the
+   \module{__future__} module.
  \end{funcdesc}