[Sjoerd]
I have some fixes for the imageop module to make it work on systems with a different byte-order than IRIX (e.g. Linux). Shall I check them in or is it not worth it for such an old module? Anything else that needs to be changed when I check this in? The fixes of course will result in different results on Linux than before, so that's the main reason for asking.
Guido van Rossum wrote:
I don't see imageop in the list of deprecated modules in PEP 4, and apparently *you* are still using it, so as long as you don't mind being potentially the sole maintainer and user, I don't mind these being in the distribution.
What do you mean by different results on Linux? Was this module previously doing something bogus there?
[Sjoerd]
The main difference is: *************** *** 570,577 **** r = (r<<5) | (r<<3) | (r>>1); g = (g<<5) | (g<<3) | (g>>1); b = (b<<6) | (b<<4) | (b<<2) | b; ! nvalue = r | (g<<8) | (b<<16); ! *ncp++ = nvalue; } return rv; } --- 560,569 ---- r = (r<<5) | (r<<3) | (r>>1); g = (g<<5) | (g<<3) | (g>>1); b = (b<<6) | (b<<4) | (b<<2) | b; ! *ncp++ = 0; ! *ncp++ = b; ! *ncp++ = g; ! *ncp++ = r; } return rv; }
where the old ncp is an "Py_UInt32 *" and the new ncp is an "unsigned char *". This results in different byte ordering on a little endian machine such as Intel.
Hm. Anybody who uses the imageop module currently on Linux will find their programs broken. The strings manipulated by imageop all end up either being written to a file or handed to some drawing code, and changing the byte order would definitely break things! So I don't think this is an acceptable change. I take it that for IRIX, the byte order implied by the old code is simply wrong? Maybe the module can be given a global (shrudder?) byte order setting that you can change but that defaults to the old setting? --Guido van Rossum (home page: http://www.python.org/~guido/)