Python's context managers are a very neat way of handling code that needs a teardown once you are done. Python objects have do have a destructor method ( __del__ ) called right before the last instance of the object is about to be destroyed. You can do a teardown there. However there is a lot of fine print to the __del__ method. A cleaner way of doing tear-downs is through Python's context manager , manifested as the with keyword. class CrushMe: def __init__(self): self.f = open('test.txt', 'w') def foo(self, a, b): self.f.write(str(a - b)) def __enter__(self): return self def __exit__(self, exc_type, exc_val, exc_tb): self.f.close() return True with CrushMe() as c: c.foo(2, 3) One thing that is important, and that got me just now, is error handling. I made the mistake of ignoring all those 'junk' arguments ( exc_type, exc_val, exc_tb ). I just skimmed the docs and what popped out is that you need to return True or
Just a heads up that Unison does not support extended attributes beyond Finder information.
ReplyDeleteYou know, that explains something that puzzled me for a while: I was trying out cocoviewx for picture organization. I tested it by commenting on two photos. The first time I synched using Unison it went fine (these photos were id-d as having changed). The next time, again the photos were identified as having changed - when I hadn't touched them. I looked at the Unison comment, and it said permissions had been changed. This happened repeatedly - I thought the server on which the backup was sitting was 'touch'-ing the files or something. Finally Jon (from our lab) pointed me to os x extended attributes and such. I used xattr to get rid of the extended attributes that cocoviewx silently put into my pictures. The problem stopped from then on...
ReplyDelete