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
holger krekel wrote:
On a side note, I don't see too much point in having __except__
return something when it is otherwise easy to say:
def __except__(self, typ, val, tb):
self.abort_transaction()
raise typ, val, tb
It has to do with "Errors should never pass silently, unl
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
Thomas Heller <[EMAIL PROTECTED]> writes:
> I always wondered why there usually is very sloppy error checking in
> init functions.
Laziness, I presume...
> The problem is that when one of these things fail (although they are
> probably supposed to NOT fail) you end up with a module missing
> som
Brett C. wrote:
>>You means sysconfig.py, right?
Right.
> No, I mean Python's setup.py; line 174.
Ah, ok.
> You mean Distutils' sysconfig, right? I can change that as well if you want.
Please do; otherwise, people might see strange effects.
Regards,
Martin
___
[Facundo Batista]
> Is there a document that details which objects are cached in memory
> (to not create the same object multiple times, for performance)?
The caches get cleaned-up before Python exit's, so you can find them all
listed together in the code in Python/pythonrun.c:
/* Sundry
On 4/21/05, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>for dummy in synchronized(the_lock):
>BODY
>
> or perhaps even (making "for VAR" optional in the for-loop syntax)
> with
>
>in synchronized(the_lock):
>BODY
>
> Then synchronized() could be written cleanly as follo
I always wondered why there usually is very sloppy error checking in
init functions. Usually it goes like this (I removed
declarations and some other lines for clarity):
PyMODINIT_FUNC
PyInit_zlib(void)
{
m = Py_InitModule4("zlib", zlib_methods,
zlib_module_documentatio
Nick Coghlan wrote:
> An alternative would be to replace the 'yield None' with a 'break' or
> 'continue', and create an object which supports the resource protocol
> and NOT the iterator protocol. Something like:
>
> def my_resource():
> print "Hi!" # Do entrance code
> continue # Go on
Nick Coghlan wrote:
> Interestingly, with this approach, "for dummy in my_resource()" would still
> wrap
> the block of code in the entrance/exit code (because my_resource *is* a
> generator), but it wouldn't get the try/finally semantics.
>
> An alternative would be to replace the 'yield None
Shane Hathaway wrote:
There's a lot of boilerplate code there. Using your suggestion, I could
write that something like this:
def transaction():
begin_transaction()
try:
continue
except:
abort_transaction()
raise
else:
18 matches
Mail list logo
