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 at acm.org>
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4