On, Tue Aug 28, 2007, Brian Fisher wrote: > On 8/27/07, René Dudfield <renesd@xxxxxxxxx> wrote: > > ah, I mean we need to make a surfarray module with the PixelArray > > module - so that the surfarray keeps backwards compatibility. > > > > So the plan is to make a python module which uses PixelArray to make a > > surfarray compatible module. > > > So If I've got the idea here right - the idea is to have pygame have a > surfarray and sndarry module that return a PixelArray or such class > instead of a numeric array, right? No. They use Numeric (or Numpy) arrays - PixelArray just acts as a locking and buffer proxy. > > I don't have any surfarray or sndarray based code in any of my > projects - but it seems to me that if I did, unless the objects > returned were 100% compatible and performance comparable with numeric True, if that'd be the case. > arrays, I would rather have the surfarray and sndarray modules > continue to be compiled in as they are - optional modules with a > dependency on numeric. Basically the dependency situation wouldn't be And here the problems begin. We would have to maintain both, Numpy and Numeric as dependencies, thus writing new setup checks, C code, etc.. A buffer object (and PixelArray's purpose for Numeric/Numpy is to act as buffer and lock object) solves this by letting us move those dependencies into plain python code and let the user (or system) use the appropriate bindings. This allows us to get rid of some compile-time checks and C code while having a more flexible Numeric/Numpy access, which even allows users to use their own array definitions, PIL interaction and whatever else. They've got direct buffer access on demand. > any worse than it was before, and it would give me the highest > confidence my code is still good. > > Then for people who don't want to have code dependent on numeric, they > can just write their code to use the new "PixelArrayView" object, > which you have to use differently. Right. That's why I added 2D access and stuff to it. > So I guess basically I'm asking, do people really want to have > surfarray change to be (mostly) compatible sans numeric, or would it > be better to have the old stuff be as is, and just have a new system > unencumbered by having to simulate the old one? If you'd followed the recent discussions about numpy vs. numeric in pygame, you would understand what brought us to this type of solution. People kept asking about moving the whole system to Numpy as Numeric development is stalled. Dropping Numeric would mean breaking with backwards compatibility as Numpy differs slightly from Numeric. I hope to have listed the main reasons, why a new object for the buffer and lock is needed here. Once more, the other parts about PixelArray such as slicing, etc. are _no_ replacements for the Numeric or Numpy functions - they are just some nice enhancements for those, who do not want to let their code rely on one of those yet need some handy direct pixel access with the one or other goodie. Regards Marcus
Attachment:
pgpAOUD2FOYwP.pgp
Description: PGP signature