Nick Coghlan wrote:
> I think the key benefit relates to the fact that correctly written resource
> management code currently has to be split it into two pieces - the first piece
> before the try block (e.g. 'lock.acquire()', 'f = open()'), and the latter in
> the finally clause (e.g. 'lock.release()', 'f.close()').
>
> PEP 343 (like PEP 310 before it) makes it possible to define the correct
> resource management *once*, and then invoke it via a 'with' (or 'do')
> statement.
sure, but even if you look at both the application code *and*
the resource management, there are no clues that the "with"
statement is really just a masked "try/finally" statement. just
look at the generator example:
acquire
yield
release
what in this snippet tells you that the "release" part will run even if
the external block raises an exception? you could at least change
that to
acquire
try:
yield
finally:
release
which would make it a lot more obvious what's going on here.
also, come to think of it, adding a new statement just to hide
try/finally statements is a waste of statement space. why not
just enhance the existing try statement? let
try with opening(file) as f:
body
except IOError:
deal with the error (you have to do this anyway)
behave like
try:
f = opening(file)
try:
try:
body
except:
exc = sys.exc_info()
else:
exc = None
finally:
f.__cleanup__(exc)
except IOError:
deal with the error
and you're done. (or you could use __enter__ and __exit__ instead,
which would give you a variation of PEP-343-as-I-understand-it)
compared to a separate statement, the worst that can happen here,
usage-wise, is that you'll end up adding an "except: raise" line here
and there to propagate real exceptions rather than dealing with them
in place. on the other hand, for the cases where you actually want
to deal with the exceptions, you'll save a line of code. I think that's
a net win.
but I still think that something closer to the original PEP 340 is a lot
more useful.
</F>
_______________________________________________
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
