In article <[EMAIL PROTECTED]>, Timothy Fitz <[EMAIL PROTECTED]> wrote:
> > No, as except clauses can only occur before the finally clause, and > > execution > > should not go backwards. > > This restriction feels a bit arbitrary. I can guarantee someone is > going to flatten this: > > try: > try: > A > finally: > B > except IOError: > C > > A more flexible approach would be to allow finally at the beginning or > ending of the try statement. A more flexible approach would be to > allow both, or even finally clauses mixed in. > > To me, that's the ugly portion of this proposal, it's quite arbitrary. > And the alternatives I posted have their own brands of ugly. I strongly disagree. It makes sense to me, anyway, that "finally" can only be the final clause and that it always does exactly what it says: execute as the final bit of the try statement. I think this would be a useful enhancement. It simplifies the published documentation a bit (no need to document try/except as a separate entity from try/finally) and I have plenty of cases where I'd like to take advantage of it. > Concisely, this is an arbitrary shortcut for an idiom that already > exists. It seems to me that this shortcut would be redundant if PEP > 340 or something with similar functionality was accepted. I do see your point here and I'll be curious to see how this shapes up (given the lengthy discussion going on about this tricky proposal). But I also feel that the unification of try/except and try/finally is truly an improvement to the language. To me it feels like a simplification -- it removes an artificial, annoying and unnecessary split. -- Russell _______________________________________________ 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
