Some CDs will cause Python 2.3 to generate a warning
when executing DiscID.disc_id. The warning will be
something like
FutureWarning: x<<y losing bits or changing sign will
return a long in Python 2.4 and up
and it will point to this line
discid = ((checksum % 0xff) << 24 | total_time << 8 | last)
as the offender. The problem is that for checksum >
127, the 24-place bitshift will turn on the most
significant bit and flip the sign. It doesn't give a
wrong answer, it just makes Python complain.
(What's really annoying about this complaint is that I
don't get it in Python 2.2 and it will apparently go
away in 2.4. But since I'm now using 2.3...)
There's probably a way to turn off the warning in my
program, but I chose to modify DiscID.py instead.
Changing the offending line to
discid = ((long(checksum) % 0xff) << 24 | total_time <<
8 | last)
prevents the MSB from being set by creating a long
integer before the bitshift. This is an explicit
version of what Python 2.4 will apparently do implicitly.
Logged In: YES
user_id=204526
This looks like the right fix, although, to be creative, I delayed the
promotion to long until after the modulus is taken:
discid = (long(checksum % 0xff) << 24 | total_time << 8 | last)
In python 2.3 you can also get warnings like:
CDDB.py:32: FutureWarning: %u/%o/%x/%X of negative int will return
a signed string in Python 2.4 and up
query_str = (('%08lx %d ') % (disc_id, num_tracks))
But with the change above, the disc_id becomes long instead of int, so,
no warning, and no problem.
In Python 2.2 and before, 32-bit unsigned numbers can be stored as
short int values. In Python 2.4 and after, 32-bit unsigned numbers with
the most significant binary digit set are automagically stored as long
int values. Python 2.3 has one foot on each side of the fence, ouch!