Brian Fisher wrote:
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
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
<[EMAIL PROTECTED]>
