On Fri, Feb 07, 2003 at 06:41:21PM +0100, Bertrand Lamy wrote: > Do we really need P3_image to be accessible in Python? > I think it would be better to use directly the image class of the PIL rather than >our own. Here is an example of what I have in mind:
I don't think it's necessary to have any references to PIL in the Soya Python code. If someone were using Pygame, for instance, they would probably want to use the Pygame image loading routines. Likewise, I might want to create a synthetic image using Numerical Python. All three of these have the ability to produce Python strings that are usable by all the tools. Having a stripped down image class in Soya just seems to be the cleanest way to provide an interface that doesn't discriminate among ways to load/make an image. I suppose one could also write a simple Python wrapper that holds a string, a type, a size, and an option, or just use a tuple of these. I don't see how that's different from just having the class wrap a pointer to a P3_image, and wrapping P3_image will give better performance because the image data will only need to be copied once for any given image. Another argument for this way of doing things is that everybody else does it that way: Pygame allows you to make surfaces from a string, size, and format; this is how to get images into Numeric arrays, and this is how one gets an image from any of these tools into PyOpenGL. I don't see why Soya should be any different, since I think one of the most import charactistics Soya needs to have is ease of learning. This is probably the most important charactistic Python has, and the Python developers work very hard on keeping consistent interfaces across modules. One problem with sharing image data is that memory management becomes a bit more difficult, though, so this could be an argument for converting from Python types each time an image is used in Soya. Of course, Soya could also be linked against Boehm's conservative garbage collector :)
msg00114/pgp00000.pgp
Description: PGP signature
