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.
> >
> > nnorwitz@usf-cf-alpha-linux-1:~/python/dist/src$ ./python
> > Python 2.3a0 (#15, Dec 18 2002, 15:52:53)
> > [GCC 2.95.4 20011002 (Debian prerelease)] on linux2
> > Type "help", "copyright", "credits" or "license" for more information.
> > >>> 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.
how the code manages it is beyond me, though. (I don't even see a
"datetime" module in my CVS tree)
Jeff
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