Brian Fisher wrote:
On 8/27/07, Lenard Lindstrom <len-l@xxxxxxxxx> wrote:Brian Fisher wrote:On 8/26/07, Marcus von Appen <mva@xxxxxxxxxxxx> 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 propagateso 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
I fear I was the source of some confusion. I misunderstanding how the buffer interface worked. I believe I understand it now. Now to this post.
This is a reasonable way to expect PixelArray locking to work. But the PixelArray also provides the buffer interface to an object. The buffer interface will allow the surfarray* module to be rewritten in a Numeric/numpy independent way. But for surface locking to work properly a PixelArray object must keep the surface locked while the object is alive.
PixelArray is also available to Pygame users. Being a Pygame specific type, should a PixelArray object lock a surface for the duration of the object? Probably not, since reliance on the garbage collector for resource management is not recommend. The context manager and the with statement were introduced to Python 2.5 to make resource management explicit and reliable. Maybe the buffer interface would be better handled by a lightweight, disposable object that does nothing else.
[*] I assume the same applies to sndarray. -- Lenard Lindstrom <len-l@xxxxxxxxx>