[Python-checkins] CVS: python/dist/src/Doc/ref refa1.tex,1.1,1.2

Fred L. Drake fdrake@users.sourceforge.net
Fri, 23 Mar 2001 08:20:49 -0800


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

Modified Files:
	refa1.tex 
Log Message:

Revise the markup so that this formats and uses markup consistently with
the rest of the documentation.


Index: refa1.tex
===================================================================
RCS file: /cvsroot/python/python/dist/src/Doc/ref/refa1.tex,v
retrieving revision 1.1
retrieving revision 1.2
diff -C2 -r1.1 -r1.2
*** refa1.tex	2001/03/23 15:29:54	1.1
--- refa1.tex	2001/03/23 16:20:46	1.2
***************
*** 1,21 ****
! \chapter{Appendix: Future statements and nested scopes}
  
  The semantics of Python's static scoping will change in version 2.2 to
  support resolution of unbound local names in enclosing functions'
  namespaces.  The new semantics will be available in Python 2.1 through
! the use of a future statement.  This appendix documents these two
  features for Python 2.1; it will be removed in Python 2.2 and the
  features will be documented in the main sections of this manual.
  
! \section{Future statements}
! \indexii{future}{statement}
  
! A \dfn{future statement} is a directive to the compiler that a
! particular module should be compiled using syntax or semantics that
! will be available in a specified future release of Python.  The future
! statement is intended to ease migration to future versions of Python
! that introduce incompatible changes to the language.  It allows use of
! the new features on a per-module basis before the release in which the
! feature becomes standard.
  
  \begin{verbatim}
--- 1,23 ----
! \chapter{Future statements and nested scopes \label{futures}}
! \sectionauthor{Jeremy Hylton}{jeremy@alum.mit.edu}
  
+ 
  The semantics of Python's static scoping will change in version 2.2 to
  support resolution of unbound local names in enclosing functions'
  namespaces.  The new semantics will be available in Python 2.1 through
! the use of a ``future'' statement.  This appendix documents these two
  features for Python 2.1; it will be removed in Python 2.2 and the
  features will be documented in the main sections of this manual.
+ 
  
! \section{Future statements \label{future-statements}}
  
! A \dfn{future statement}\indexii{future}{statement} is a directive to
! the compiler that a particular module should be compiled using syntax
! or semantics that will be available in a specified future release of
! Python.  The future statement is intended to ease migration to future
! versions of Python that introduce incompatible changes to the
! language.  It allows use of the new features on a per-module basis
! before the release in which the feature becomes standard.
  
  \begin{verbatim}
***************
*** 53,57 ****
  
  The direct runtime semantics are the same as for any import statement:
! there is a standard module \file{__future__.py}, described later, and
  it will be imported in the usual way at the time the future statement
  is executed.
--- 55,59 ----
  
  The direct runtime semantics are the same as for any import statement:
! there is a standard module \module{__future__}, described later, and
  it will be imported in the usual way at the time the future statement
  is executed.
***************
*** 66,80 ****
  \end{verbatim}
  
! That is not a future statement; it's an ordinary import statement, with
  no special semantics or syntax restrictions.
  
  Code compiled by an exec statement or calls to the builtin functions
! \function{compile} and \function{execfile} that occur in a module M
! containing a future statement will use the new syntax or semantics
! associated with the future statement.
  
  A future statement typed at an interactive interpreter prompt will
  take effect for the rest of the interpreter session.  If an
! interpreter is started with the \emph{-i} option, is passed a
  script name to execute, and the script includes a future statement, it
  will be in effect in the interactive session started after the script
--- 68,82 ----
  \end{verbatim}
  
! That is not a future statement; it's an ordinary import statement with
  no special semantics or syntax restrictions.
  
  Code compiled by an exec statement or calls to the builtin functions
! \function{compile()} and \function{execfile()} that occur in a module
! \module{M} containing a future statement will use the new syntax or
! semantics associated with the future statement.
  
  A future statement typed at an interactive interpreter prompt will
  take effect for the rest of the interpreter session.  If an
! interpreter is started with the \programopt{-i} option, is passed a
  script name to execute, and the script includes a future statement, it
  will be in effect in the interactive session started after the script
***************
*** 84,91 ****
  	 Future statement definitions}
  
! \declaremodule{standard}{__future__}
  \modulesynopsis{Future statement definitions}
  
! \file{__future__.py} is a real module, and serves three purposes:
  
  \begin{itemize}
--- 86,93 ----
  	 Future statement definitions}
  
! \declaremodule[future]{standard}{__future__}
  \modulesynopsis{Future statement definitions}
  
! \module{__future__} is a real module, and serves three purposes:
  
  \begin{itemize}
***************
*** 96,100 ****
  \item To ensure that future_statements run under releases prior to 2.1
        at least yield runtime exceptions (the import of
!       \code{__future__} will fail, because there was no module of
        that name prior to 2.1). 
  
--- 98,102 ----
  \item To ensure that future_statements run under releases prior to 2.1
        at least yield runtime exceptions (the import of
!       \module{__future__} will fail, because there was no module of
        that name prior to 2.1). 
  
***************
*** 102,106 ****
        will be --- or were --- made mandatory.  This is a form of executable
        documentation, and can be inspected programatically via importing
!       \code{__future__} and examining its contents.
  
  \end{itemize}
--- 104,108 ----
        will be --- or were --- made mandatory.  This is a form of executable
        documentation, and can be inspected programatically via importing
!       \module{__future__} and examining its contents.
  
  \end{itemize}
***************
*** 112,117 ****
  \end{verbatim}
  
! where, normally, OptionalRelease <  MandatoryRelease, and both are
! 5-tuples of the same form as \code{sys.version_info}:
  
  \begin{verbatim}
--- 114,119 ----
  \end{verbatim}
  
! where, normally, OptionalRelease is less then MandatoryRelease, and
! both are 5-tuples of the same form as \code{sys.version_info}:
  
  \begin{verbatim}
***************
*** 136,148 ****
  use such imports. 
  
! MandatoryRelease may also be None, meaning that a planned feature got
! dropped.
  
  Instances of class \class{_Feature} have two corresponding methods,
! \member{getOptionalRelease()} and \member{getMandatoryRelease()}.
  
! No feature line will ever be deleted from \file{__future__.py}.
  
- \section{Nested scopes}
  \indexii{nested}{scopes}
  
--- 138,152 ----
  use such imports. 
  
! MandatoryRelease may also be \code{None}, meaning that a planned
! feature got dropped.
  
  Instances of class \class{_Feature} have two corresponding methods,
! \method{getOptionalRelease()} and \method{getMandatoryRelease()}.
! 
! No feature description will ever be deleted from \module{__future__}.
! 
  
! \section{Nested scopes \label{nested-scopes}}
  
  \indexii{nested}{scopes}