On Wed, Dec 18, 2002 at 06:30:34PM -0600, Jeff Epler wrote: > On Wed, Dec 18, 2002 at 08:04:40PM -0500, Tim Peters wrote: > > [Neal Norwitz] > > > I used the alpha in the SF compile to verify the bug. The problem was > > > originally reported on the snake-farm from the test suite. > > > > > > >>> from datetime import timedelta > > > >>> timedelta(1, 7, 31) > > > datetime.timedelta(1, 7, 31) > > > >>> _.days, _.seconds, _.microseconds > > > (30064771073, 133143986183, 31) > > > > It's really no help. The *first* thing to do is to build Python with > > optimzation disabled. Try a debug build, if possible, and step thru > > delta_new(). Luckily, that's the hairiest code in the whole module <wink>. > > > > Putting the "wrong parts" in hex, that result is > > > > (0x700000001L, 0x1F00000007L, 31) > ^ ^ (0x1F) > ^^ ^^ > > which suggests nothing to me. > > something is sure suggested to me by those numbers. It's as though > successive members are 4 bytes apart, but they're being treated as 8 bytes > wide, or something. That kept bugging me. I just checked in the fix. The problem was the accessors members for days, seconds, and microseconds were T_LONGs instead of T_INTs. Test passes on alpha & x86 for me. Neal
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