why is a negative shift value illegal?

[Rainer Deyke]

"Tim Peters" <tim.one at home.com> wrote in message
news:mailman.979455916.32613.python-list at python.org...
> [Rainer Deyke]
> > I don't buy the speed argument.
>
> If that implies you do buy the other arguments, there's no point haggling
> over the weakest one <0.5 wink>.

No, it implies that I did not have an immediate response to the others.

> > Consider 16 bit color formats.
> > ...
>
> OK, I did.  I concluded that if I were doing significant amounts of pixel
> twiddling, I sure as heck wouldn't be writing it in Python no matter what
> gimmicks were added to shifts (an extension module, sure, but not in
Python
> proper).  OTOH, if I weren't doing significant amounts, speed would be a
> non-issue.

My argument wasn't just about speed.  Consider again the code to calculate
the red component of a color:

red = ((color & red_mask) >> red_position) << (8 - red_length)

Right now this fails if red_length is greater than 8.  Fixing this is
possible, but messy:

red_right_shift = red_postion + red_length - 8
if red_right_shift < 0:
  red_left_shift = -red_right_shift
  red_right_shift = 0
else:
  red_left_shift = 0

red = ((color & red_mask) >> red_right_shift) << red_left_shift

I'm using 16 bit colors as an example, but the same principle applies to
many other cases.

> In every case Python raises an exception, *someone* eventually says "hey!
> let's make it mean something instead!".  That way lies madness.  Allowing
> negative shift counts simply isn't a compelling idea,

Mostly because shifts themselves are only rarely used.


--
Rainer Deyke (root at rainerdeyke.com)
Shareware computer games           -           http://rainerdeyke.com
"In ihren Reihen zu stehen heisst unter Feinden zu kaempfen" - Abigor