At 01:55 PM 5/14/2005 +0200, Fredrik Lundh wrote:
>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)
I like this, if you take out the "with" part, change the method names to
__try__ and __finally__, and allow "try" to work as a block on its own if
you've specified an expression. i.e.:
try opening(filename) as f:
# do stuff
try locking(self.__lock):
# do stuff
try redirecting_stdout(f):
# something
try decimal.Context(precision=23):
# okay, this one's a little weird
try self.__lock:
# and so's this; nouns read better with a gerund wrapper
and I'd make the translation be:
try:
__exc = ()
VAR = EXPR.__try__()
try:
try:
BODY
except:
__exc = sys.exc_info()
raise
finally:
EXPR.__finally__()
# except/else/finally clauses here, if there were any in the original try
>but I still think that something closer to the original PEP 340 is a lot
>more useful.
I agree, but mainly because I'd like to be able to allow try/finally around
"yield" in generators, be able to pass exceptions into generators, and tell
generators to release their resources. :)
I do think that the PEP 340 template concept is much more elegant than the
various PEP 310-derived approaches, though.
_______________________________________________
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
