[Python-Dev] Fixes for imageop module

[Guido van Rossum]

> >>>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/)