Well I'm sorry for polluting the list with another wild idea.
It often happens that you have to do some cleanup of multiple resources,
but those cleanup functions may raise an exception. Yet you wanna clean
all the resources. So you end up writing something like this :
def finish(self):
try:
Antoine wrote:
> try:
> self.db_transaction.commit()
> then:
> self.tmpoutfile.close()
> then:
> self.destroy_shared_memory_handle()
> except Exception, e:
> logging.error("an exception occurred in cleanup: %s", e)
Can you explain the difference to:
try:
self.db_transaction
> Can you explain the difference to:
>
> try:
> self.db_transaction.commit()
> self.tmpoutfile.close()
> self.destroy_shared_memory_handle()
> except Exception, e:
> logging.error("an exception occurred in cleanup: %s", e)
In your construct, if self.db_transaction.commit() rai
Antoine wrote:
> I thought it would be nice to have an idiom where several blocks of code
> are tried in order, regardless of whether they throw an exception or not:
>
> try:
>self.db_transaction.commit()
> then:
>self.tmpoutfile.close()
> then:
>self.destroy_shared_memory_handle()
> e
Antoine wrote:
>> Can you explain the difference to:
>>
>> try:
>> self.db_transaction.commit()
>> self.tmpoutfile.close()
>> self.destroy_shared_memory_handle()
>> except Exception, e:
>> logging.error("an exception occurred in cleanup: %s", e)
>
> In your construct, if self.d
In reference to the discussion of assignment to variables in outer
scopes: I get the sense that there are a substantial number of folks who
are in agreement on the basic semantics, and the only sticking point
is exactly what keyword to pick.
(I should mention that I'm still off to the side in
Now that I've gotten your attention :)
Seriously, though, I am not proposing that there *never* be additions to
the standard library -- instead, I simply want 'easy_install' to work
100% of the time, so that there's much less reason to add something to
the standard library.
In fact, I would go
On Oct 13, 2006, at 7:39 AM, Talin wrote:
Now that I've gotten your attention :)
Seriously, though, I am not proposing that there *never* be
additions to
the standard library -- instead, I simply want 'easy_install' to work
100% of the time, so that there's much less reason to add something
Talin wrote:
> Seriously, though, I am not proposing that there never be additions
> to the standard library -- instead, I simply want 'easy_install' to
> work 100% of the time, so that there's much less reason to add
> something to the standard library.
-1000.
The standard library is not ab
