On Aug 15, 2007, at 6:43 PM, Matthew Scott wrote: > I'll try my best to get these modified accordingly too -- it would be > nice if at least _most_ of the unit tests passed on Windows, so that > future versions of Durus will be easier to verify Windows > compatibility with :-) I would like that, and as of this afternoon, I am equipped to help. I finally took the time to get my Python 2.5.1 on Vista on Parallels on MacBook Pro setup working. I was able to run some unit tests this afternoon. The first thing I noticed is that Popen4 can't be imported from popen2, but "popen4" can. > Pat O'Brien is usually pretty keen on high performance:opcode ratios, > and his influence on me over the years is probably what prompted me to > include that code in the first place. Understood. I guess I'm more interested in keeping the source code as easy as possible to understand. In fact, when I edited file.py to include the different versions of several methods depending on the os.name, I retreated, realizing that I had been down that path before and the pattern in the current code is really the pattern I prefer. I just put the conditional flush in the current write() method and I do like it that way. The extra time for the "if" must surely be tiny compared to the time of the underlying write(), even without the extra flush(). > We have a lot of code in Schevo where a method will do something like > this at the beginning, in order to speed up loops and especially > nested loops that rely on those variables a lot: > > def foo(self): > bar = self.bar > baz = self.baz > # ... > > Sometimes there are around ten lines like that at the beginning of > a method. :) Does this make your customers happier? > But as I said, your decision is fine with me either way. When I am > done with the broad strokes I will probably go ahead and do some > benchmarks comparing the two methods, just so there is more to reason > with than just code style when making decisions like this. I like that approach. Thanks again for your efforts. David