On Sat, Apr 23, 2005, Nick Coghlan wrote:
In light of Alex's comments, I'd actually like to suggest the below as a potential new definition for PEP 310 (making __exit__ optional, and adding an __else__ handler):
if hasattr(x, '__enter__'): x.__enter__() try: try: # Contents of 'with' block except: if hasattr(x, '__except__'): if not x.__except__(*sys.exc_info()): # [1] raise else: raise else: if hasattr(x, '__else__'): x.__else__() finally: if hasattr(x, '__exit__'): x.__exit__()
+1, but prior to reading this post I was thinking along similar lines with your __exit__ named __finally__ and your __else__ named __exit__. My reasoning for that is that most of the time, people want their exit condition aborted if an exception is raised; having the "normal" exit routine called __else__ would be confusing except to people who do lots of exception handling.
In the original motivating use cases (file handles, synchronisation objects), the resource release is desired unconditionally. The aim is to achieve something similar to C++ scope-delimited objects (which release their resources unconditionally as the scope is exited). This parallel is also probably the source of the names of the two basic functions ('enter'ing the contained block, 'exit'ing the contained block).
So, I think try/finally is the right semantics for the basic __enter__/__exit__ use case (consider that PEP 310 is seen as possibly worthwhile with *only* these semantics!).
For error logging type use cases, only the exception handling is required. The issue of a 'no exception raised' handler only comes up for cases like transactions, where the commit operation is conditional on no exception being triggered. I understand you agree that, for those cases, the best spot to call the handler is an else clause on the inner try/except block. That way, it is skipped by default if an exception goes off, but the exception handling method can still invoke the method directly if desired (e.g. an exception is determined to be 'harmless'.
However, I do agree with you that the use of '__else__' as a name is exposing too much of the underlying implementation (i.e. you need to understand the implementation for the name to make sense). I think renaming '__exit_' to '__finally__' would be a similar error, though.
Which means finding a different name for '__else__'. Two possibilities that occur to me are '__ok__' or '__no_except__'. The latter makes a fair amount of sense, since I can't think of a way to refer to the thing other than as a 'no exception' handler.
Cheers, Nick.
P.S. I'm ignoring my housemate's suggestion of '__accept__' for the no-exception handler :)
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---------------------------------------------------------------
http://boredomandlaziness.skystorm.net
_______________________________________________
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
