> >[Phillip J. Eby] > > > FYI, there are still use cases for clearing the exception state in an > > > __exit__ method, that might justify allowing a true return from __exit__ > > > to > > > suppress the error. e.g.: > >[...]
[Guido] > >Yes, but aren't those written clearer using an explicit try/except? > >IMO anything that actually stops an exception from propagating outward > >is worth an explicit try/except clause, so the reader knows what is > >happening. [Phillip] > I thought the whole point of PEP 340 was to allow abstraction and reuse of > patterns that currently use "try" blocks, including "except" as well as > "finally". Indeed it was. But I'm getting a lot of pushback on the PEP so I'm exploring a simpler proposal with a more limited use case -- that of PEP 310, basically. Note that generators written for this new proposal do not contain try/finally or try/except (and don't need it); they simply contain some actions before the yield and some actions after it, and the with/do/block/stmt statement takes care of calling it. > So, if you're only going to allow try/finally abstraction, > wouldn't it make more sense to call it __finally__ instead of > __exit__? That would make it clearer that this is purely for try/finally > patterns, and not error handling patterns. I don't think the name matteres that much; __exit__ doesn't particularly mean "error handling" to me. I think PEP 310 proposed __enter__ and __exit__ and I was just following that; I've also thought of __enter__/__leave__ or even the nostalgic __begin__/__end__. > As for whether they're written more clearly using an explicit try/except, I > don't know. Couldn't you say exactly the same thing about explicit > try/finally? For try/finally we have a large body of use cases that just scream for abstraction. I'm not convinced that we have the same for try/except. Maybe the key is this: with try/finally, the control flow is unaffected whether the finally clause is present or not, so hiding it from view doesn't matter much for understanding the code; in fact in my mind when I see a try/finally clause I mentally translate it to something that says "that resource is held for the duration of this block" so I can stop thinking about the details of releasing that resource. try/except, on the other hand, generally changes the control flow, and there is much more variety in the except clause. I don't think the need for abstraction is the same. > For that matter, if you used function calls, doesn't it > produce the same issue, e.g.: > > def retry(count,exc_type=Exception): > def attempt(func): > try: func() > except exc_type: pass > for i in range(count-1): > yield attempt > yield lambda f: f() > > for attempt in retry(3): > attempt(somethingThatMightFail) > > Is this bad style too? Yes (not to mention that the retry def is unreadable and that the 'attempt' callable feels magical). There are many ways of coding retry loops and seeing the bottom two lines (the use) in isolation doesn't give me an idea of what happens when the 3rd attempt fails. Here, EIBTI. -- --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
