Looks like this harmless-looking issue has opened up a can of worms.

> the whole idea of OverflowError seems slightly outdated.

Well, not entirely.  It's still got a place for overflow of mathematical operations, and I think it's clearly the correct exception in that case (indeed, it's about the only case I can think of where OverflowError is clearly the correct exception).

>>> from math import exp
>>> exp(5000.0)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OverflowError: math range error

I'd treat conversion to float as a special case of this; that is, the following is another case where OverflowError is (IMO) the right thing to use:

>>> float(10**1000)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OverflowError: long int too large to convert to float

A less clear-cut case:

>>> sqrt(10**500)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OverflowError: long int too large to convert to float

This one still seems okay to me, even though the sqrt result *is* within the floating-point range.  You can read this as two operations: a conversion from the integer input to a float, followed by a floating-point square root operation, and it's the intermediate result that overflows.

And a case that's clearly wrong:

>>> 53 >> 10**100  # Why not simply return 0?
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OverflowError: Python int too large to convert to C ssize_t

Another historical oddity is that OverflowError inherits from ArithmeticError (along with FloatingPointError and ZeroDivisionError), which supports its use for arithmetic and mathematical operations that overflow their target type.

>>> OverflowError.__mro__
(<class 'OverflowError'>, <class 'ArithmeticError'>, <class 'Exception'>, <class 'BaseException'>, <class 'object'>)


In the interests of moving this *particular* issue forward, I'll revert to OverflowError for this patch.  I still personally think it's the wrong exception, but:

(1) It's not more wrong than before: we were already raising OverflowError for large positive values.
(2) It achieves the main aim of replacing an obscure error message with a more understandable one (which is what Nick wanted in the first place: msg210454).
(3) Given the lack of clarity about which exception types are appropriate where, I think we shouldn't be changing exception types unless/until there's a clear vision of where we want to end up.  Getting that clear vision may require a python-dev discussion.

We can still make the change from OverflowError to ValueError at some later point once it's clear that that's the right thing to do.  But converting from OverflowError to ValueError now, and then deciding later that that was wrong and converting back to OverflowError would be a horrible thing to do.