Hey Lenard, thanks for testing the script I sent. The results confirm that an earlier statement "p's lifetime will be limited to the with ... : block anyhow" is not true, meaning with as wouldn't be supported merely by making the PixelArray object lock and unlock as it is created and deleted.
Also, I think what you proposed as an implementation of __exit__ below wouldn't be sufficient (reasons below) On 8/27/07, Lenard Lindstrom <[EMAIL PROTECTED]> wrote: > Brian Fisher wrote: > > On 8/26/07, Marcus von Appen <[EMAIL PROTECTED]> wrote: > __exit__ simply releases the surface lock: > def __exit__(self, exc_type, exc_val, exc_tb): # exception stuff is ignored > self.unlock() # Assumes PixelArray has an unlock method. > return False # let any exceptions propagate > so if __exit__ just calls unlock, than how would PixelArray know not to unlock when destructs? thereby unlocking one too many times. Also, because __enter__ doesn't lock, you wouldn't be able to use "with" on the same PixelArray twice (a very reasonable way to try and use it, if you are someone who uses the "with" statement with locks in order to define critical section stuff) in particular, I think a proper "with" implementation ought to be able to support something like this: p = PixelArray(surface) with p: p.do_stuff() with p: p.do_more_stuff() ... while getting the locking all right
