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:
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
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
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
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
[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
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
___
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
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
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 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__'):
>
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
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
>>
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
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:
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
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
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
18 matches
Mail list logo
