[Python-Dev] Fixes for imageop module (original) (raw)

Guido van Rossum guido at python.org
Fri Jan 9 11:13:32 EST 2004

>>>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.

--Guido van Rossum (home page: http://www.python.org/~guido/)

More information about the Python-Dev mailing list