Toby Dickenson 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__'.
I quite like .acquire() and .releas
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
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__'.
I quite like .acquire() and .release().
T
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.
Wh
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.
While we're on th
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:
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 or
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
>>
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 transaction(obje
On Sat, Apr 23, 2005 at 13:41 +1000, Nick Coghlan wrote:
> 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__'):
>
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:
>
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.__excep
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:
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 th
Hi all,
probably unsuprisingly i am still pondering the idea of having
an optional __except__ hook on block handlers. The PEP says this
about this:
An extension to the protocol to include an optional __except__
handler, which is called when an exception is raised, and which
can han
[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__()
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 that are ok to fail.
With
17 matches
Mail list logo
