Because you are using a 32-bit int and in Java all ints are signed (the  
most significant bit is negative).  Presumably the Python value is an  
unsigned 32-bit type?

Use a long to avoid this (long is signed too but if you are not using the  
full range of values it won't cause you a problem).

That's because they are the same in binary, it's just how the most  
significant bit is interpretted that is different.

Dan.

..which is correct, assuming a left-shift means that the value is multiplied
by 2 raised to the power of 24, although it is not common because usually
the behaviour is inherited from the CPU which uses a limited amount of
digits.

..which may or may not be correct, depending on the definition. At least for
C, I believe that this causes "undefined behaviour", which is why you
should avoid using shift operations on signed types there, rather use
unsigned types. I guess that Java's VM is defined so that its shift
operations assume twos complement representations of signed integers. Can
anyone clarify that?

Further, Python as opposed to C or Java is dynamically typed. That means
that the results of

 255 << 20
 255 << 30

not only yield different values but also different types! This gives Python
the ability to switch to a bigger representation type where it would
overflow in C or Java. See the output of

 type(255 << 20)
 type(255 << 30)

for example.

This is due to the fact that both are represented by the same sequence of
bits, which are only interpreted differently. Other interpretations would
be as a floating point number or a sequence of characters.

Uli