Shane Hathaway wrote:
Nick Coghlan wrote:
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.
Toby Dickenson [EMAIL PROTECTED] wrote:
On Sunday 24 April 2005 07:42, Nick Coghlan wrote:
Shane Hathaway wrote:
While we're on the subject of block handler method names, do the method
names need four underscores? 'enter' and 'exit' look better than
'__enter__' and '__exit__'.
[EMAIL PROTECTED] (holger krekel) wrote:
basically translates to:
if hasattr(x, '__enter__'):
x.__enter__()
try:
...
except:
if hasattr(x, '__except__'): x.__except__(...)
else: x.__exit__()
else:
x.__exit__()
Nope...
On Apr 22, 2005, at 16:51, holger krekel wrote:
Moreover, i think that there are more than the transactional
use cases mentioned in the PEP. For example, a handler
may want to log exceptions to some tracing utility
or it may want to swallow certain exceptions when
its block does IO operations
On Fri, Apr 22, 2005 at 19:03 -0700, Josiah Carlson wrote:
[EMAIL PROTECTED] (holger krekel) wrote:
basically translates to:
if hasattr(x, '__enter__'):
x.__enter__()
try:
...
except:
if hasattr(x, '__except__'): x.__except__(...)
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:
Nick Coghlan wrote:
Alternately, PEP 310 could be defined as equivalent to:
if hasattr(x, '__enter__'):
x.__enter__()
try:
try:
...
except:
if hasattr(x, '__except__'):
x.__except__(*sys.exc_info())
else:
At 01:41 PM 4/23/05 +1000, Nick Coghlan wrote:
Whichever way that point goes, this definition would allow PEP 310 to
handle Alex's example of factoring out standardised exception handling, as
well as the original use case of resource cleanup, and the transaction
handling:
class
Nick Coghlan [EMAIL PROTECTED] writes:
holger krekel wrote:
Moreover, i think that there are more than the transactional
use cases mentioned in the PEP. For example, a handler may want to
log exceptions to some tracing utility or it may want to swallow
certain exceptions when
its block
Bernhard Herzog wrote:
With the proposed implementation of PEP 310 rev. 1.5 it wouldn't work.
sys.exc_info returns a tuple of Nones unless an except: clause has been
entered. Either sys.exc_info() would have to be changed to always
return exception information after an exception has been raised
Aahz wrote:
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:
11 matches
Mail list logo
