> pixels: A list of arrays (array.array). Each array in the list is a line in the image. Each array is the actual image data for that line in the image.

This seems like a silly thing to do. It would make for much more readable code to use numpy arrays. But regardless, the pixel data should be one single array of data.

It looks to me like the guy working on this hasn’t spent tremendously much time thinking about good image APIs. Is there any document that describes the design goals and process?

Numpy support in PyPy is being worked on. Meanwhile arrays are well-tested and jit-accelerated.

array.array is fine, I guess, but using a list of array.array objects is inelegant and inflexible. It’s much better to put all your image data in one big array, keep track of the various stride lengths to go down rows or across pixels, and then implement proper multi-dimensional indexing.

I suppose it doesn’t really matter. This library is also missing all the other flexibility you’d want in a general imaging toolkit – e.g. the assumption of 8 bit/channel RGB is baked into everything, with no notion of color space or gamma encoding (and the JPEG decoder doesn’t seem to have any mention of color spaces, meaning that many JPEG images will be wrongly interpreted). It’s not usable for any but the most basic image processing tasks.

The JPEG decoder might make an okay benchmark for pypy performance, though it’s a straight port from C++, so it’s probably not the style of python code that pypy is designed to be fast on.

I believe Jonas is approaching it from his position as a web developer and Django author who's spent a LOT of time dealing with requests from people who've had trouble with PIL and generally only use 8-bit RGB.

I'd be reluctant to condemn a project which is a few days old. Having spent time wrestling with optimizing the horror which is the PIL code, I'd definitely suggest that having a pure Python implementation will make it much easier for people to experiment with API and performance improvements.