[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