[Python-checkins] CVS: python/nondist/peps pep-0227.txt,1.4,1.5

[Jeremy Hylton]

Update of /cvsroot/python/python/nondist/peps
In directory slayer.i.sourceforge.net:/tmp/cvs-serv10958

Modified Files:
	pep-0227.txt 
Log Message:
Clarify rules for names defined in class scope.  (Classes hide names
was a bad label.)

Add note about how to implement flat closures using an extra level of
indirection.  



Index: pep-0227.txt
===================================================================
RCS file: /cvsroot/python/python/nondist/peps/pep-0227.txt,v
retrieving revision 1.4
retrieving revision 1.5
diff -C2 -r1.4 -r1.5
*** pep-0227.txt	2000/12/14 14:40:45	1.4
--- pep-0227.txt	2000/12/14 14:53:02	1.5
***************
*** 57,65 ****
      If a name is used within a code block, but it is not bound there
      and is not declared global, the use is treated as a reference to
!     the nearest enclosing function region.  A region is visible from a
!     block is all enclosing blocks are introduced by function
!     defintions. (Note: If a region is contained within a class
!     definition, the name bindings that occur in the class block are
!     not visible to enclosed functions.)
  
      A class definition is an executable statement that may uses and
--- 57,63 ----
      If a name is used within a code block, but it is not bound there
      and is not declared global, the use is treated as a reference to
!     the nearest enclosing function region.  (Note: If a region is
!     contained within a class definition, the name bindings that occur
!     in the class block are not visible to enclosed functions.)
  
      A class definition is an executable statement that may uses and
***************
*** 112,128 ****
      with three primary exceptions:
  
!         - Class definitions hide names.
          - The global statement short-circuits the normal rules.
          - Variables are not declared.
  
!     Class definitions hide names.  Names are resolved in the innermost
!     enclosing function scope.  If a class defintion occurs in a chain
!     of nested scopes, the resolution process skips class definitions.
!     This rule prevents odd interactions between class attributes and
!     local variable access.  If a name binding operation occurs in a
!     class defintion, it creates an attribute on the resulting class
!     object.  To access this variable in a method, or in a function
!     nested within a method, an attribute reference must be used,
!     either via self or via the class name.
  
      An alternative would have been to allow name binding in class
--- 110,126 ----
      with three primary exceptions:
  
!         - Names in class scope are not accessible.
          - The global statement short-circuits the normal rules.
          - Variables are not declared.
  
!     Names in class scope are not accessible.  Names are resolved in
!     the innermost enclosing function scope.  If a class defintion
!     occurs in a chain of nested scopes, the resolution process skips
!     class definitions.  This rule prevents odd interactions between
!     class attributes and local variable access.  If a name binding
!     operation occurs in a class defintion, it creates an attribute on
!     the resulting class object.  To access this variable in a method,
!     or in a function nested within a method, an attribute reference
!     must be used, either via self or via the class name.
  
      An alternative would have been to allow name binding in class
***************
*** 296,310 ****
  
      There are a variety of implementation alternatives for closures.
!     One possibility is to use a static link from a nested function to
!     its enclosing environment.  This implementation requires several
!     links to be followed if there is more than one level of nesting
!     and keeps many garbage objects alive longer than necessary.
! 
!     One fairly simple implementation approach would be to implement
!     the default argument hack currently used for lambda support.  Each
!     function object would have a func_env slot that holds a tuple of
!     free variable bindings.  The code inside the function would use
!     LOAD_ENV to access these bindings rather than the typical
!     LOAD_FAST.
  
      The problem with this approach is that rebindings are not visible
--- 294,308 ----
  
      There are a variety of implementation alternatives for closures.
!     Two typical ones are nested closures and flat closures.  Nested
!     closures use a static link from a nested function to its enclosing
!     environment.  This implementation requires several links to be
!     followed if there is more than one level of nesting and keeps many
!     garbage objects alive longer than necessary.
! 
!     Flat closures are roughly similar to the default argument hack
!     currently used for lambda support.  Each function object would
!     have a func_env slot that holds a tuple of free variable bindings.
!     The code inside the function would use LOAD_ENV to access these
!     bindings rather than the typical LOAD_FAST.
  
      The problem with this approach is that rebindings are not visible
***************
*** 329,332 ****
--- 327,334 ----
      definition time.  This is the default argument hack, but not
      actual name resolution based on statically nested scopes.
+ 
+     To support shared visibility of updates, it will be necessary to
+     have a tuple of cells that contain references to variables.  The
+     extra level of indirection should allow updates to be shared.
  
      It is not clear whether the current 1-pass Python compiler can