Guido van Rossum wrote:
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!
That's why I asked.
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?
The problem is, the documentation says: "This is the same format as used by gl.lrectwrite() and the imgfile module." This implies the byte order that you get on the SGI which is opposite of what you get on Intel. The code produced the correct results on the SGI, but not on Intel.
Your fix would be okay if until now it was *only* used on IRIX with gl.lrectwrite() and/or the imgfile module. But how can we prove that?
I don't know.
(By the way, I'm away from computers for a week starting tomorrow extremely early.)
It's okay to way a week before making a decision.
I'm back (and have been this week). Any thoughts about a decision?
I suggest that you implement a way to change the endianness of the operations. A global flag in the module is fine. It should default to the historic behavior, and there should be a call to switch it to the behavior you want.
I submitted a patch (874358) to SourceForge. -- Sjoerd Mullender <sjoerd@acm.org>