Update: same result for md5. Now what?

[Tim Peters]

[Thomas Weholt]
> [on sha and md5 returning the same hash for two different files]
> The files are different. Is there something about jpg-compressed
> files that I should know about?

[Neil Schemenauer]
> Its pretty hard to test this without having the two files your
> using.  Can you either make them available or try using something
> like the md5sum command to verify the hash your getting from
> Python?

>
>     >>> hash = md5.new(open('test.py').read()).digest()
> ...

Neil, you're encouraging the poor man to repeat his original mistake <wink>:
from the file paths in his original report, it was clear that he was running
on Windows,  but opening binary files in text mode.  I have no doubt that
Andrew set him on the right path already (i.e., add "rb" to his open()
calls).  Files opened in text-mode under Windows take the first instance of
chr(26) as meaning "end of file", which is a huge gotcha non-Windows people
are just blind to.  Curiously, the Windows behavior is perfectly fine
according to the C standard, and is indeed one of many reasons the std
distinguishes between text and binary modes despite that Unixoids believe
they're the same.

Whether it's proper for Python to continue following C's madness here in P3K
would be a darned good question, and one I may have already taken a stand on
as I see my fingers called it "madness" while I wasn't looking <wink>.

in-the-meantime-it-will-continue-to-bite-everyone-in-the-strangest-
    places-ly y'rs  - tim