The REALLY bad thing about Python lists ..

[Tim Peters]

[Tim]
> ISO/ANSI C doesn't fully define what happens when (roughly)
> integer division or % are handed negative numbers.

[Glyph]
> The foibles of standards commitees will never cease to amuse me.
> Thank you for this little tidbit.

[Russell Wallace]
> Don't blame the C committee, blame the CPU manufacturers.  C doesn't
> define the result because CPUs aren't consistent about what result they
> give.

That's exactly what makes it critical for languages to define it:  a prime
charter of most languages is to aid portability, not expose accidents of the
hardware du jour.  No language is more concerned about speed or peaceful
coexistence with oddball hardware than Fortran, and the Fortran folks
defined integer division as truncating long before the C committee dropped
the ball on this one.  The C9X std repairs that failing, albeit by following
Fortran's rule.  Ironic:  the primary effect of the "speed conscious"
refusal to define it before was that use of signed int division and modulo
in C was banned by many government coding standards, which mandated use of
(much slower) external library functions instead.

> (Under what circumstances would you want to use % on negative numbers?
> I can't think of any.)

Anytime something "wraps around".  Think circles, like clocks or, well,
circles <wink>.  If the big hand is pointing at 10 now, where was it
pointing 45 minutes ago?  At (10-45) % 60 == 25 in Python, undefined in the
current C, and the systematically unhelpful -35 in C9X.  Mod *with respect
to* a negative number is indeed rare, but mod wrt a positive number is very
common, and it's in the very nature of "wrapping around" that you can go in
either direction (positive or negative).  Python's rules assure that the
result is always >= 0 then, which is almost always what you want.

saving-a-nanosecond-doesn't-help-sell-a-wrong-answer-ly y'rs  - tim