Gregory P. Smith writes: > heh good point. ignore that thought. python is a signed language. :)
For what little it's worth, I object strongly. The problem isn't Python, it's C. Because the rules give unsigned precedence over signed in implicit conversions, mixed signed/unsigned arithmetic in C is just a world of pain. It's especially dangerous when dealing with Unix-convention stream functions where non-negative returns are lengths and negative returns are error codes. Often the only indication you get is one of those stupid "due to insufficient range of type comparison is always true" warnings. In my experience except when dealing with standard functions of unsigned type, it's best to avoid unsigned like the plague. It's worth the effort of doing a range check on an unsigned return and then stuffing it into a signed if you got one big enough. Sign me ... "Escaped from Unsigned Purgatory in XEmacs" _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
