Long overdue updates.

A decision one way or the other should be made wrt. this PEP at some
point, I guess.
This commit is contained in:
Michael W. Hudson 2003-12-15 11:04:01 +00:00
parent 3ba0a893ba
commit 33602533d2
1 changed files with 62 additions and 17 deletions

View File

@ -66,8 +66,10 @@ Basic Syntax and Semantics
suite suite
finally: finally:
if hasattr(var, "__exit__"): var.__exit__()
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 If the variable is omitted, an unnamed object is allocated on the
stack. In that case, the suite has no access to the unnamed object. stack. In that case, the suite has no access to the unnamed object.
@ -117,18 +119,6 @@ Possible Extensions
Implementation Notes 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 There is a potential race condition in the code specified as
equivalent to the with statement. For example, if a equivalent to the with statement. For example, if a
KeyboardInterrupt exception is raised between the completion of KeyboardInterrupt exception is raised between the completion of
@ -157,8 +147,19 @@ Open Issues
If a way of controlling object lifetimes explicitly was available, If a way of controlling object lifetimes explicitly was available,
the function of the __exit__ hook could be taken over by the the function of the __exit__ hook could be taken over by the
existing __del__ hook. Unfortunately, no workable proposal for existing __del__ hook. An email exchange[1] with a proponent of
controlling object lifetimes has been made so far. 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.
Alternative Ideas Alternative Ideas
@ -166,6 +167,17 @@ Alternative Ideas
IEXEC: Holger Krekel -- generalised approach with XML-like syntax IEXEC: Holger Krekel -- generalised approach with XML-like syntax
(no URL found...) (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 Backwards Compatibility
@ -173,11 +185,45 @@ Backwards Compatibility
to be played. to be played.
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 References
There are various python-list and python-dev discussions that There are various python-list and python-dev discussions that
could be mentioned here. 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 Copyright
@ -191,4 +237,3 @@ indent-tabs-mode: nil
sentence-end-double-space: t sentence-end-double-space: t
fill-column: 70 fill-column: 70
End: End: