> [Tim]
> > This raises a question: what should crc32 and adler32 return?
> > ...
> > binascii.crc32() always-- even on 64-bit boxes --returns a value in
> > range(-2**31, 2**31).
> > ...
> > I don't know what the other guys return (zlib.crc32(),
> > zlib.adler32(), ...?).
> >
> > It would sure be nice if they returned values in range(0,
> > 2**32) instead. A difficulty with changing this stuff is that
> > checksums seem frequently to be read and written via the struct
> > module, with format code "l", and e.g.
> >
> > >>> struct.pack("!l", 1L << 31)
> > Traceback (most recent call last):
> > File "<stdin>", line 1, in ?
> > OverflowError: long int too large to convert to int
> [Guido]
> > Such programs will have to be changed to use format code "L" instead.
[Tim]
> I'm not following this. At least binascii.crc32() always produces a 32-bit
> signed int now, so there's no *need* to use "L" now. Are you saying that
> binascii.crc32() should be changed to return a non-negative value always?
> Also the other xyz.abc32() functions?
Um, I thought *you* were proposing that! What else did you mean by
"It would sure be nice if they returned values in range(0, 2**32)
instead" ?
> > Or perhaps "l" should be allowed to accept longs in
> > range(-2**31, 2**32) ?
>
> Well, unpacking a packed value wouldn't always return the value you
> started with then (pack 2**31 via "l", then unpack it via "l" and
> you get back -2**31), so it's not very attractive. If you dump a
> checksum via pack, then unpack it later, you really want to get back
> the same value, not just "the same bits after some fiddling".
Yeah, you can't win. :-(
--Guido van Rossum (home page: http://www.python.org/~guido/)
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