On, Fri Aug 24, 2007, Lenard Lindstrom wrote: > Marcus von Appen wrote: >> On, Thu Aug 23, 2007, Lenard Lindstrom wrote: [...] >>> probably expects a string, which is a copy of the data. But there was a >>> big discussion not so long ago on comp.lang.pygame about relying on >>> garbage collection to release a resource. Maybe all locked surfaces >>> should be explicitly unlocked. Should a PixelArray support context >>> management (with statement)? >>> >> >> Explicitly unlocking would mean calling unlock (and maybe lock) for >> about 90% of the offered functions. I do not think that this is an >> option. >> >> What do you mean with context management exactly here? >> >> > > I am still somewhat confused. This is your example: Now I am confused :-). Why are you confused? When you mentioned explicit unlocking, I thought you mean unlocking should not be done by the deallocation routines of the object's implementation, which implicitly locks a surface. [...] > I will try and give a context managed version: > > sf = pygame.Surface ((10, 20)) > sf.fill ((0, 0, 0)) > with PixelArray(sf) as p: > buffer_request(p) > > The PixelArray __enter__ method simply returns self. __exit__ unlocks the > parent surface and invalidates the array. That's definitely something that should be supported once Python 2.6 is available. As far as I understand p's lifetime will be limited to the with ... : block anyhow, so it'll be (implicitly) deleted once the scope is left (and the surface thus will be automatically unlocked - even in the current implementation). For now it's nothing we need to take care of however. Regards Marcus
Attachment:
pgp9nFm8TSjvU.pgp
Description: PGP signature