32 bit arithmetic in 2.3+

[Robin Becker]

In article <bnfq46$8v1$0 at 216.39.172.122>, Bengt Richter <bokr at oz.net>
writes
.
......
>
>I guess the messages mean that your int objects are not the same as what int is
>to mean soon. So maybe being explicit might be the way to go? E.g.,
>
>    class int32(int):
>       # ... make it work the way you want... or make a separate int32 
>extension
>
>and use int32 instances where you have int instances now? It would also 
>document
>your 32-bit assumptions/requirements.
>
>What do your 32-bit entities represent? Perhaps there is something even more
>appropriate than integers?

I think you're right. These things represent the checksums done in
typical C code where int means 32 bit unsigned. Of course the C code
will go wrong when it moves to a 64 bit machine, but I didn't design
true type fonts or the pdf encryption algorithms.
>
>If you do need good-old-32-bit-ints modeling typical 32-bit ALU behavior, and a
>lot of people need that, maybe there ought to be a built-in int32 type, or a
>parameterized fixed-width metatype, so you could say int32 = 
>int_fixed_width(32)
>or int_sixty_four = int_fixed_width(64) etc. and tie into efficient 
>implementation.
>

This seems like an excellent idea. I suppose it could be done in Python
first to provide a reference implementation.

>Just a few rambling thoughts...
>
>Regards,
>Bengt Richter

It seems a bit funny to issue Future Warnings about things that I cannot
import a __future__ feature and test any fix.
-- 
Robin Becker