A quick response to various small issues...
- Benji York proposes that file and lock objects (for example) could
have suitable __enter__ and __exit__ methods (__enter__ would have
to return self). Right!
- Greg Ewing (I believe) wants 'do' instead of 'with' for the
keyword. I think I like 'with' better, especially combining it with
Benji's proposal. IMO this reads better with 'with' than with 'do':
with open("/etc/passwd") as f:
for line in f:
...
- Steve Bethard has this example:
stmt = EXPR1
VAR1 = stmt.__enter__()
exc = () # or (None, None, None) if you prefer
try:
try:
BLOCK1
except:
exc = sys.exc_info()
finally:
if stmt.__exit__(*exc) is not None:
raise exc[0], exc[1], exc[2]
but he seems to forget that finally *always* re-raises the
exception. Anyway, I still don't care for the use case; rather than
fixing the coding bug, your time would be better spent arguing why
this functionality can't be missed.
- Eric Nieuwland asks if the VAR is still optional. Yes, it is (this
is implicit in the entire set of threads).
- Paul Moore wants the generator templates to explicitly contain
try/finally (or try/except, depending on the use case). That's much
more work though (passing exceptions into a generator is a new
feature) and is not necessary to get the "redux" version.
- Ka-ping Yee thinks we need separate entry points for the exceptional
and the normal termination case. I disagree; this would end up in
unnecessary duplication of code (or boilerplate to equate the two
methods) in most cases. The whole *point* is that finally gets to
do its clean-up act regardless of whether an exception is being
processed or not. The varargs signature to __exit__ was just me
being lazy instead of typing
def __exit__(self, t=None, v=None, tb=None): ...
- Nick is still peddling his much more complicated variant. I
recommend that he focuses on arguing use cases rather than semantic
subtleties, or else it won't get any traction (at least not with me
:-).
--Guido van Rossum (home page: http://www.python.org/~guido/)
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
