why is a negative shift value illegal?

[Tim Peters]

[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>.

> ...
> 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.

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, and seems at least as
likely to mask program bugs as to do anyone a lick of real good.  I've
gotten ValueErrors from shift counts that mistakenly went negative, and I'm
glad I did (shifting "in the other" direction would have been dead wrong).
I'm still one-quarter unhappy that modern Python allows, e.g.

    sequence[-1]

Python originally called that an error, and that caught bugs too.  But at
least indexing "from the right" is very useful very often for very many
programmers (e.g., string[:-1] is probably in every Python programmer's
idiom bag).

if-you-still-like-it-write-a-pep!-ly y'rs  - tim