[Python-checkins] python/nondist/peps pep-0310.txt,1.2,1.3

mwh at users.sourceforge.net mwh at users.sourceforge.net
Mon Dec 15 06:04:03 EST 2003


Update of /cvsroot/python/python/nondist/peps
In directory sc8-pr-cvs1:/tmp/cvs-serv32421

Modified Files:
	pep-0310.txt 
Log Message:
Long overdue updates.

A decision one way or the other should be made wrt. this PEP at some 
point, I guess.


Index: pep-0310.txt
===================================================================
RCS file: /cvsroot/python/python/nondist/peps/pep-0310.txt,v
retrieving revision 1.2
retrieving revision 1.3
diff -C2 -d -r1.2 -r1.3
*** pep-0310.txt	10 Feb 2003 15:34:54 -0000	1.2
--- pep-0310.txt	15 Dec 2003 11:04:01 -0000	1.3
***************
*** 67,72 ****
  
  	finally:
! 	    if hasattr(var, "__exit__"):
! 		var.__exit__()
  
      If the variable is omitted, an unnamed object is allocated on the
--- 67,74 ----
  
  	finally:
!             var.__exit__()
! 
!     Note that this makes using an object that does not have an
!     __exit__() method a fail-fast error.
  
      If the variable is omitted, an unnamed object is allocated on the
***************
*** 118,133 ****
  Implementation Notes
  
-     The optional assignment in
- 
-         'with' [ var '=' ] expr ':'
- 
-     was initially considered to be too hard to parse correctly.
-     However, by parsing the statement as
- 
-         'with' expr [ '=' expr ] ':'
- 
-     and interpreting the result in the compiler phase, this can be
-     worked around.
- 
      There is a potential race condition in the code specified as
      equivalent to the with statement.  For example, if a
--- 120,123 ----
***************
*** 158,163 ****
      If a way of controlling object lifetimes explicitly was available,
      the function of the __exit__ hook could be taken over by the
!     existing __del__ hook.  Unfortunately, no workable proposal for
!     controlling object lifetimes has been made so far.
  
  
--- 148,164 ----
      If a way of controlling object lifetimes explicitly was available,
      the function of the __exit__ hook could be taken over by the
!     existing __del__ hook.  An email exchange[1] with a proponent of
!     this approach left one of the authors even more convinced that
!     it isn't the right idea...
! 
!     It has been suggested[2] that the "__exit__" method be called
!     "close", or that a "close" method should be considered if no
!     __exit__ method is found, to increase the "out-of-the-box utility"
!     of the "with ..." construct.
! 
!     There are some simiralities in concept between 'with ...' blocks
!     and generators, which have led to proposals that for loops could
!     implement the with block functionality[3].  While neat on some
!     levels, we think that for loops should stick to being loops.
  
  
***************
*** 167,170 ****
--- 168,182 ----
                              (no URL found...)
  
+     Holger has much more far-reaching ideas about "execution monitors"
+     that are informed about details of control flow in the monitored
+     block.  While interesting, these ideas could change the language
+     in deep and subtle ways and as such belong to a different PEP.
+ 
+     Any Smalltalk/Ruby anonymous block style extension obviously
+     subsumes this one.
+ 
+     PEP 319 is in the same area, but did not win support when aired on
+     python-dev.
+ 
  
  Backwards Compatibility
***************
*** 174,177 ****
--- 186,209 ----
  
  
+ Cost of Adoption
+ 
+     Those who claim the language is getting larger and more
+     complicated have something else to complain about.  It's something
+     else to teach.
+ 
+     For the proposal to be useful, many file-like and lock-like
+     classes in the standard library and other code will have to have
+ 
+         __exit__ = close
+ 
+     or similar added.
+ 
+ 
+ Cost of Non-Adoption
+ 
+     Writing correct code continues to be more effort than writing
+     incorrect code.
+ 
+ 
  References
  
***************
*** 179,182 ****
--- 211,228 ----
      could be mentioned here.
  
+     [1] Off-list conversation between Michael Hudson and Bill Soudan
+         (made public with permission)
+         http://starship.python.net/crew/mwh/pep310/
+ 
+     [2] Samuele Pedroni on python-dev
+         http://mail.python.org/pipermail/python-dev/2003-August/037795.html
+ 
+     [3] Thread on python-dev with subject
+ 
+         [Python-Dev] pre-PEP: Resource-Release Support for Generators
+ 
+         starting at
+ 
+         http://mail.python.org/pipermail/python-dev/2003-August/037803.html
  
  Copyright
***************
*** 192,194 ****
  fill-column: 70
  End:
- 
--- 238,239 ----





More information about the Python-checkins mailing list