It usually doesn't just mean "outside a required range", it means "outside the range of values representable due to implementation specific limitations (e.g. the function is converting to a C type)". You don't raise OverflowError because your function only allows values from 0-1000, you raise it because you accept "arbitrary" values that are in fact limited by the definition of int, long, Py_ssize_t, etc. It does get weird when you talk about unsigned values, where they're usually used because negative values aren't logically valid, not merely a side-effect of trying to use more efficient types. Case #3 mentioned in Terry's list is because it's stored as a C unsigned char, which simply doesn't support values outside the range [0,256).

I think of the distinction between ValueError and OverflowError as the difference between "The argument makes no logical sense in context" and "The argument can't be used due to interpreter limitations". I suppose it makes sense to be consistent; if your function only accepts values from 0-1000 on a logical basis, then any OverflowErrors should be converted to ValueErrors (since no change in implementation would alter the accepted logical range).

I'll grant it gets fuzzy when we talk about bytes (after all, the function could choose to use a larger storage type, and probably didn't because program logic dictates that [0,256) is the value range). Not sure how it's possible to handle that, or if it's even worth it when so much code, APIs, and third party modules are saying that implementation limits (OverflowError) trump logical limits (ValueError) when it comes to the exception type.