On 8/15/07, David Binger  wrote:
> Thanks very much, Matt, for finding and fixing this bug
> that shows up for Durus ShelfStorage on Windows.

Not all the Durus tests pass on Windows yet :)  But that may be due to
some tricks that the tests are doing in certain situations, such as
line 83 of utest_file_storage, where it calls f.flush() after g has
been assigned a FileStorage instance with the same filename as f.

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


> As I understand it, the actual fix to the original problem you found
> is the additional self.file.flush() at the end of the write()
> method.  I'm just glad we don't need that on non-nt systems.

Correct.  I'm glad, too :)  It was very perplexing to find out that
that was what was needed.  Perhaps a more efficient long-term solution
would be to add calls to flush() at more specific points on Windows,
rather than after every write(), but then that would go against the
grain of having an OS-neutral abstraction :)


> I'm not so hot on the read(), tell() optimization.  I understand
> the intent, and I think I may have tried that myself back when I
> first write the File class, but it doesn't seem worth it, especially
> with the extra effort required to keep rename working.
> Is that okay with you?

It's okay with me, although I'll submit that the File class probably
won't get extended much further than its current implement.

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.

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

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.


--
Matthew R. Scott